AAAARCH Research Group A. Taal INTERNET DRAFT G. Sliepen Category: Informational A.E. Hemel C.T.A.M. de Laat November 2001 A grammar for 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 docuí ments 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 (2001). All Rights Reserved. A. Taal et al. Expires: June 2002 [Page 1] Internet Draft Grammar for Policies in Generic AAA November 2001 Abstract In this document a formal model of a language to describe policies is presented in the context of a generic AAA environment. In such an environment, multiple domains or "kingdoms" are involved. Each domain has, in effect, Service Level Agreements (SLAs) with other domains. Those SLAs and other rules that may apply to a domain are implemented as policies in AAA Servers. The policies should facilií tate AAA Servers from the various domains to work together in order to Satisfy Requests from users for services that cross those domains. For complex services, not all knowledge can be packed into a single policy. Therefore, a policy must be able to reference another policy. This might be a reference to a local policy, policy stored at the same AAA Server, as well as a reference to a remote policy, a policy stored at a remote AAA Server. Other important components of a policy are calls to generic functions the AAA Server is equipped with, and the possibility to delegate special tasks to so called Application Specific Modules. 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' . . . . . . . . . . . . . . 5 2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . . 5 2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . . 6 2.4. The Use Case 'Authenticate User' . . . . . . . . . . . . . 6 2.5. The Use Case 'Authorize User' . . . . . . . . . . . . . . 6 3. Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Formal model . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Constants and variables . . . . . . . . . . . . . . . . 12 3.2.3. Object trees . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Policy references . . . . . . . . . . . . . . . . . . . 14 3.2.5. Actions . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Construction guidelines . . . . . . . . . . . . . . . . . 16 3.5. Example Policy . . . . . . . . . . . . . . . . . . . . . . 18 3.6. Pushing Policies . . . . . . . . . . . . . . . . . . . . . 21 References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 A. Taal et al. Expires: June 2002 [Page 2] Internet Draft Grammar for Policies in Generic AAA November 2001 1. AAA environment +---+ +---+ |AAA|<=============================================>|AAA| +---+<============= =========>+---+ /\ /\ \\ // /\ /\ || || || || || || || \/ || || || \/ \/ +--+ || || \/ +--+ +---+ |PR| || || +---+ |PR| |ASM| +--+ \/ \/ |ASM| +--+ +---+ +---+ +---+ +---+ |AAA|<=============>|AAA| +---+ +---+ /\ /\ /\ /\ || || || || || \/ || \/ \/ +--+ \/ +--+ +---+ |PR| +---+ |PR| |ASM| +--+ |ASM| +--+ +---+ +---+ Figure 1. The abstract view of a generic AAA environment This section introduces an abstract view of a generic AAA environí ment [RFC2903], and what kind of components it consists of. Only those components 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 contents of the request contain 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. The Driving Policy specifies the behavior of the AAA Server for a certain request. For each message type of a future AAA protocol [OBJMSG] there exists a corresponding Driving Policy that is evaluated. Whether the request will be accepted or rejected depends on the evaluation of the Driving Policy. In case the Driving Policy is part of a distributed policy, the AAA Server that receives the request has to communicate with other AAA Servers in order to fully evaluate the request. Complex and special tasks not possible or too cumbersome to express into the policy language are handled by generic components or by Application Specific Modules (ASMs). Because Driving Policies can refer to local policies and to ASMs for complex tasks, the contents of the Policy Repository (PR) and the ASMs determine the behavior of the AAA Server. A change of the A. Taal et al. Expires: June 2002 [Page 3] Internet Draft Grammar for Policies in Generic AAA November 2001 contents 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. 2. Use Case Diagram +-+ +-+ | request +-----------------+ <> ----- <=========> | Satisfy Request |============ | +-----------------+ || / \ || \/ User || <> +-----------------------+ \/ | Lookup Driving Policy | +-------------------------+ +-----------------------+ | Evaluate Driving Policy *<==== +-------------------------+ \\ <> /\ \\ policy requires <> || \\ authorization policy requires || || authentication || || +-------------------+ +----------------+ | Authenticate User | | Authorize User | +-------------------+ +----------------+ Figure 2. Use Case diagram for a request 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. 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 to be satisfied, the Use Case 'Satisfy Request'. The relationship between the Actor and this Use Case is a bi-direcí tional 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 A. Taal et al. Expires: June 2002 [Page 4] Internet Draft Grammar for Policies in Generic AAA November 2001 - Actors: User - Precondition: none In total we distinguish five Use Cases: - 'Satisfy Request' - 'Lookup Driving Policy' - 'Evaluate Driving Policy' - 'Authenticate User' - 'Authorize User' 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 relationí ships are interpreted as conditional include relationships. The Use Cases 'Authenticate User' and 'Authorize User' are only perí formed 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 [OBJMSG]. 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 outí come of his request, especially when his request is rejected. 2.2. The Use Case 'Lookup Driving Policy' The AAA Server must retrieve the Driving Policy that needs to be 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). As there exists a one-to-one mapping between AAA requests and Driving Policies, it is clear to the AAA Server which Driving Policy it has to retrieve. A. Taal et al. Expires: June 2002 [Page 5] Internet Draft Grammar for Policies in Generic AAA November 2001 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 evalí uate all policies necessary. This task is delegated to the Rule Based Engine (RBE, see fig. 2). A complex situation occurs when a request contains a policy that is pushed by the user. If this hapí pens 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. It is the responsií bility of the AAA Server to keep track of the decision process. 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 perí formed if the Driving Policy under evaluation requires it. When that is the case, the request must contain information about necesí sary 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' 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. It is not strictly necessary to perform authentication before authorization. There are cases where the decision whether the request is authorized or not does not in any way depend on information about the user. 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 an AAA 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 believe are necí essary for any future model. There are several reasons to come with a formal model for a policy. In this document a grammar is A. Taal et al. Expires: June 2002 [Page 6] Internet Draft Grammar for Policies in Generic AAA November 2001 presented. As a Driving Policy determines the behavior of an AAA Server into a large extent, there is a tight relationship between the grammar and the architecture of an AAA Server. The type of constructions defined in the grammar influence the ways in which the ASMs will be accessed, and therefore the way the whole AAA environment will react. Policies might be distributed, i.e. a policy may reference a policy residing at another AAA Server. In that case communication between AAA Servers is involved during policy evaluation. The AAA request and response objects [OBJMSG] must be suited to accommodate the necessary information for remote policy evaluation. This shows an interdependence between the formal model and the object types of a future AAA protocol. Another important reason for a formal model of a policy is the need for pushed and pulled policies in the AAA environment. An AAA Server or even an application acting on behalf of a user should be allowed to present or request policies in an AAA Request. Obvií ously a standard protocol or language must exist so that the parí ties involved agree upon the contents of those policies. Since the AAA concept (architecture and protocol) is a complicated one, there exists a large need for simulation. As the behavior of an AAA Server is policy driven, the contents of the Policy Reposií tory will be reflected in the outcome of a simulation. The need for simulation comes from the hope to proof the decidability of policies in a distributed, generic AAA system. 3.2. Formal model There can be many definitions of a policy grammar. The grammar we propose here is NOT presented as an official AAA policy grammar. However, we present it to pinpoint some elements, which will most likely be part of an official AAA policy grammar. We also present it to facilitate the discussion about AAA policies, and to document this language in order to explain the results of a possible simulaí tion of a generic AAA system. The notation of the grammar below is in EBNF (Extended Backus Naur Formalism), terminal symbols are placed between double quotes: Policy ::= "if" "(" Condition ")" "then" "(" ActionList ")" "else" "(" ActionList ")" Condition ::= BoolExpr BoolExpr ::= Bool A. Taal et al. Expires: December 2001 [Page 7] Internet Draft Grammar for Policies in Generic AAA November 2001 | Var | ComputedBoolean | {Var "="}? Procedure | Policy | UnaryBooleanOperator BoolExpr | "(" BoolExpr BinaryBooleanOperator BoolExpr ")" UnaryBooleanOperator ::= "!" BinaryBooleanOperator ::= "&&" | "||" Procedure ::= PolicyRef | FunctionCall PolicyRef ::= PolicyName "@" Hostname "(" ARGList ")" FunctionCall ::= FunctionName "(" ARGList ")" ARGList ::= {ARG {"," ARG}*}? ARG ::= Var "=" Bool | Var "=" ComputedBoolean | Var "=" NonBooleanExpr | Var "=" Procedure ActionList ::= {Action {"," Action}*}? Action ::= Var "=" Bool | Var "=" ComputedBoolean | Var "=" NonBooleanExpr | {Var "="}? Procedure | Policy ComputedBoolean ::= NonBooleanExpr ComparisonOperator NonBooleanExpr | "exists" Var ComparisonOperator ::= "==" | ">" | ">=" | "<" | "<=" | "!=" NonBooleanExpr ::= Int | Float | String | Var | UnaryArithmeticOperator NonBooleanExpr | "(" NonBooleanExpr A. Taal et al. Expires: June 2002 [Page 8] Internet Draft Grammar for Policies in Generic AAA November 2001 BinaryArithmeticOperator NonBooleanExpr ")" UnaryArithmeticOperator ::= "-" BinaryArithmeticOperator ::= "+" | "-" | "/" | "*" | "%" Var ::= Source {"." Source}* Source ::= Identifier PolicyName ::= Identifier FunctionName ::= Identifier Hostname ::= "[a-zA-Z0-9_.]+" Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*" String ::= "\"[^"\n]*\"" Int ::= "-?[0-9]+" Float ::= "-?[0-9]+\.[0-9]*(E-?[0-9]+)?" Bool ::= "(true|false)" A Policy can be viewed as an if-then-else construction. The Condií tion (if-part) yields a Boolean value, which may be the result of evaluating a larger expression. Recursion of Conditions is allowed and opens the possibility to make complex policies. Both the then-part and the else-part consist of a list of Actions. Actions are tasks to be performed, and their execution is guarded by the Condition. The Actions in the then-part are executed when the Condition is true, and the Actions in the else-part are exeí cuted when the Condition is false. To a Policy we also attach a Boolean value. We define a Policy to be true if and only if the Condition is true, and the Actions of the then-part are successí fully executed. A Policy is said to be false if and only if the Condition is false, and the Actions in the else-part are successí fully executed. In all other situations, the state of the Policy is undetermined due to the occurrence of an error. As the grammar does not provide for exception handling, the only reasonable choice is to stop the evaluation of the Policy after error occurrence. Policies can be nested in both Conditions as well as Actions. A Policy in an ActionList gives the possibility to express a more deterministic policy, while allowing a Policy within a Condition introduces the notion of `attaching Actions to sub-expressions of a A. Taal et al. Expires: June 2002 [Page 9] Internet Draft Grammar for Policies in Generic AAA November 2001 Condition'. According to the above definition it follows that, whether a Policy is part of a Condition, or is used as an Action, its truth value determines the truth value of the Policy one level up in the nestí ing. Two other components of the model are a PolicyRef and a Functioní Call. A PolicyRef is a reference to a policy that may reside in the same Policy Repository (local policy) or may reside at another AAA Server (remote policy). The component FunctionCall can be interí preted as a function call to an Application Specific Module (ASM), or more general a call of a library function the AAA Server might be equipped with. An important concept is the result of a PolicyRef and a FunctionCall. With respect to the result their is no differí ence between a PolicyRef and a FunctionCall. In general the result is an object tree, all members of the tree are accessible. The root object of the object tree contains the truth value of the PolicyRef or FunctionCall. As these components have a truth value, they can be part of a Condition or can be applied as an Action. In the next sections we will explain the syntax of the grammar accompanied with remarks about the semantics of that grammar. 3.2.1. Conditions A Condition is defined as an arbitrary Boolean formula, i.e. we don't make the restriction to a formula in DNF (Disjunctive Normal Form) or CNF (Conjunctive Normal Form) notation. The introduction of brackets ensures any ambiguity is avoided and, no precedence rules for operators or other constructions to resolve parsing coní flicts are needed. Apart from that, the conventions from the C laní guage are used. Conditions are to be evaluated from left to right. For an OR expression it holds that the right operand is not evaluí ated if the left operand evaluates to true. The same holds for the AND expression if the left operand evaluates to false. This also implies that different parts of a Policy can not be evaluated in parallel. According to this definition the following two Policies are equivaí lent: Policy 1: if ( if ( C1 ) then ( A11 ) else ( A12 ) && if ( C2 ) then ( A21 ) else ( A22 ) A. Taal et al. Expires: June 2002 [Page 10] Internet Draft Grammar for Policies in Generic AAA November 2001 ) then ( A00 ) else ( A01 ) Policy 2: if( C1 ) then ( A11; if( C2 ) then( A21; A00 ) else( A22; A01 ) ) else ( A12; A01 ) A Condition, or Boolean expression, is composed of five different types of operands (literals): Bool, Var, ComputedBoolean, Proceí dure, and Policy. An operand of type Bool, Var, ComputedBoolean, or Policy is just the Boolean value true or false. A ComputedBoolean is a comparison between a left and right hand expression. An important aspect of an expression is that it can contain variables (Var). A variable (Var) refers to a node (sub-tree) of an object tree. The corresponding dotted notation provides the RBE (Rule Based Engine) with the information where the sub-tree referenced can be retrieved. The object tree of the request always starts with the reserved word "Request", whereas the object tree of the correspondí ing reply begins with the reserved word "Reply". A reference to a policy (PolicyRef) opens the possibility to reuse local policies (policies in the same Policy Repository) as well as remote policies (policies residing in a Policy Repository managed by another AAA Server). This type may be interpreted as a Remote Procedure Call. A consequence of policy references is the need of communication between AAA Servers during policy evaluation. A future AAA protocol should provide for request/response objects in order to support referencing remote policies [OBJMSG]. The other type, FunctionCall, may be interpreted as a function call to an Application Specific Module, or as a call to a library function. Both Procedures, a PolicyRef and a FunctionCall, are equivalent in the sense that the result is an object tree. If an assignment is made all parts of this result tree are accessible in the remaining Policy. Whether or not an assignment is made, the truth value of the Procedure is implicitly used to determine the truth value of the Policy it is contained in. An example of an `Authentication Policy' illustrates some of the concepts dealt with above: if A. Taal et al. June 2002 [Page 11] Internet Draft Grammar for Policies in Generic AAA November 2001 ( Query = getPassword(userid = Request.UserID) && Request.PassW == Query.PassW ) then (...) else (...) Herein the password supplied in the Request object is compared with the password of the user stored in the authentication database. The ASM function getPassword() retrieves the password corresponding to the username that has been supplied as an argument. This argument refers to a variable called "UserID" in the Request object. By making the assignment "Query = getPassword(...)", the password in the return tree can be referred to. This is done in the right hand side of the Condition. A useful feature is the operator "exists" in combination with an object as a ComputedBoolean. This allows checking if a certain object exists in a return tree or request: if ( exists Request.Bandwidth && Request.Bandwidth >= 10 ) then (...) else (...) 3.2.2. Constants and variables The grammar allows the use of constants and variables, but like in other scripting languages (e.g. JavaScript) the grammar does not provide for type checking. Therefore, the use of variables and coní stants of different types in the same expression may result in an error state. For example the multiplication of two variables, one representing a string and the other representing a floating point number is not defined. 3.2.3. Object trees As mentioned above, variables (Vars) refer to a member of an object tree. We use the following definitions. A node is a leaf if it has no children. All other nodes are internal nodes. If a Var refers to a leaf of an object tree, it refers to a primitive type, like a bool, int, float or string value. A reference to an internal node means that the Var refers to an object, i.e. a sub-tree of the object tree starting at that specific internal node. Take for instance the Authentication Request/Reply [OBJMSG]: A. Taal et al. Expires: June 2002 [Page 12] Internet Draft Grammar for Policies in Generic AAA November 2001 AAA Client AAA Server Request: ---> - Identity - AuthenticationData <--- Reply: - Answer Suppose the Identity object in the Request object contains a string called UserID. This member of the Request object may be repreí sented as a Var (variable) with the dot-structure: Request.Idení tity.UserID. A Var refers to an empty object tree if the head of the corresponding dot-structure is not the reserved word "Request" or "Reply", and it is neither the head of a previously mentioned dot-structure. Such a Var may be interpreted as a leaf without a value. With this definition in mind the semantics of assignments with variables is the following. Consider the assignment of the form Var = Var with corresponding dot-structure A.B.C = D.E. Four different cases can be distinguished. 1. The left and right hand side both refer to already defined object trees. Then the assignment means that all children of E are copied and become the children of C. All original children of C are lost. If C is a leaf but E is a node, then C becomes a node. In case both C and E are leaves, C remains a leaf but its value is changed to the value of E. 2. The left hand side is an existing object tree whereas the right hand side is an empty (not yet declared) object tree. This means that the sub-tree of the tree at the left-hand side starting at node C is deleted. Node C becomes a leaf with no value. 3. The left-hand side is an empty object tree whereas the right-hand side is an existing object tree. This is the declaí ration of a new object tree. 4. Both sides of the assignment refer to an empty object tree. There is no need to define this as an error. As nothing has to be done, such an assignment might be ignored. It is important to notice that all assignments are assignments by value and NOT by reference. Assignment by reference would lead to undesirable effects. The assignment A.B.C = A.B would result in an object tree with node C pointing to itself. A. Taal et al. Expires: June 2002 [Page 13] Internet Draft Grammar for Policies in Generic AAA November 2001 3.2.4. Policy references There is a difference between a policy reference to a local policy and one to a remote policy. A reference to a remote policy (Polií cyRef) will initiate communication with another AAA Server. As all communication among AAA Servers will proceed via the AAA protocol, only predefined message types are used [OBJMSG]. Therefore, the name part (PolicyName) of the policy reference is limited to the name of one of these predefined message types. This restriction does not hold for references to locally stored policies. Such a reference has only a restriction with respect to the host name used. Like Procedures, a reference to a local policy might be accompanied with arguments and returns an object tree. This raises the question if a difference in syntax is necessary. A FunctionCall and a PolicyRef to a local policy might be syntactically indistiní guishable, only different name spaces will reveal if one has to deal with a generic function call, a call to an ASM, or a reference to a local policy. In general PolicyRefs are not interchangeable with the policies they refer to. 3.2.5. Actions In order to reduce unexpected effects to a minimum and make sure that different AAA Servers always exhibit the same behavior, we define the following semantics with respect to Actions. The requirements mentioned below are arbitrary in the sense that another policy language might impose different requirements. All Actions in an ActionList must always be executed immediately after evaluating the corresponding Condition. Immediately here means that Actions are executed in the order in which they appear in the ActionList, and an Action is only executed when the previous Action has finished successfully. During execution of the Actions in the ActionList, policy evaluation is postponed. Take for example the Policy below. In this example, it is clear that the Action openfirewall() of the first Policy HAS to have sucí cessfully finished BEFORE the Action sendpacket() from the second Policy is run. Otherwise it might be possible that sendpacket() will fail (because the packet can't pass the firewall if it hasn't been opened yet). if ( if ( firewallready() ) then ( openfirewall() ) else (...) A. Taal et al. Expires: June 2002 [Page 14] Internet Draft Grammar for Policies in Generic AAA November 2001 && if ( packetready() ) then( sendpacket() ) else ( closefirewall() ) ) then (...) else (...) 3.3. Errors There are several circumstances under which errors can occur during the evaluation of policies or the execution of actions. The Policy might refer to objects that are missing. A Functioní Call, for example getPassword(), might generate an error, because the password is not found in the database, or because the database is off-line. Actions can also generate errors, for instance opení firewall() may fail. Since we allow arithmetic expressions, another type of error might be caused by a division by zero or other illegal operations. As Vars might be of different types, incompatibilities might occur during evaluation of an expression, like a string multiplied by a float. Suppose that errors do not break or interfere with evaluation. If in the above example (in the previous section) openfirewall() fails, then continuing the evaluation of the Condition will cerí tainly make sendpacket() fail as well. In this example it is desirí able that the evaluation stops after the first error. However there are examples where it make sense to continue after error occurrence. The consideration whether to stop or continue after an error also holds for ActionLists. So, when an error that is not caught by whatever construction in the Policy occurs, the AAA Server either has to ignore the error and continue or abort evaluaí tion. Both choices have advantages in some situations, and disadí vantages in others. The AAA Server cannot decide for itself what is best. A possible solution might be to introduce exception handling in the grammar, so that the policy administrator can tell the AAA Server how to react in case an error occurs. Again, an `arbitrary' choice has to be made in order to make all AAA Servers react in the same way to errors. Since errors occurring early in the Policy evaluation might trigger even more errors later on, possibly resulting in a disastrous cascade, we will require that AAA Servers abort evaluation of a Policy the moment an error occurs. The administrator can make sure that the Policies are constructed in such a way that errors do not result in an undesirable A. Taal et al. Expires: June 2002 [Page 15] Internet Draft Grammar for Policies in Generic AAA November 2001 situation. This is shown in the next section. 3.4. Construction guidelines An example: +---+ | 3 | +---+ / / +---+ +---+ | 1 |------| 2 | +---+ +---+ User AAA \ \ +---+ | 4 | +---+ Suppose a User at location "1" wants bandwidth to start a one hour long video stream at time t = T from location "3" to location "4". The User issues an AAA Request, say at t = 0 to reserve the necesí sary bandwidth. This request is sent to the AAA Server at location "2" (a bandwidth broker). There the request is recognized as a request for bandwidth reservation. The User, or rather the applií cation acting on behalf of the real user, has the a priori knowlí edge which parameters are needed by the AAA Server to fulfill his request. Those parameters are added to the Service request into the object ServiceData, say: ServiceData.Bandwidth = 100, ServiceData.Source = "3", ServiceData.Destination = "4", ServiceData.StartTime = T, ServiceData.StopTime = T + 3600 A simple Driving Policy for this particular request at the AAA Server at location "2" may look like this: if ( reserveBandwidth(source = Request.Source, destination = Request.Destination, bandwidth = Request.Bandwidth, starttime = Request.StartTime, duration = (Request.StopTime - Request.StartTime)) A. Taal et al. Expires: June 2002 [Page 16] Internet Draft Grammar for Policies in Generic AAA November 2001 then ( Reply.Answer.Message = "Request for bandwidth has been satisfied" ) else (...) The reservation of the bandwidth is typically a task to be perí formed by an ASM. As the reservation of bandwidth between devices is a complicated process, different errors can occur. However, the grammar allows a nested if-then-else structure by which the occurí rence of errors can be reduced, for instance by checking the preí conditions: if ( exists Request.Bandwidth && Request.Bandwidth >= 10 ) then ( if ( Request.Bandwidth <= 500 ) then (...) else ( Reply.Answer.Message = "Requested bandwidth too large" ) ) else ( Reply.Answer.Message = "Requested bandwidth too small" ) The grammar also allows Policies nested inside Conditions. There are advantages and disadvantages to this. Take for example the following Policy which tries to send a packet through a firewall if both firewall and packet are ready: if ( if ( firewallready() ) then ( openfirewall() ) else ( Reply.Answer.Message = "Firewall not ready" ) && if ( packetready() ) then ( sendpacket() ) else ( closefirewall(); Reply.Answer.Message = "Packet not ready" ) ) then ( closefirewall() ) else (...) Note the fact that the FunctionCall closefirewall() has to appear twice in this Policy, and the fact that the second sub-expression (where the packet is sent if it is ready) now has the responsibilí ity of closing the firewall if there is a problem. Now take this functionally equivalent Policy, where the nesting is done inside A. Taal et al. Expires: June 2002 [Page 17] Internet Draft Grammar for Policies in Generic AAA November 2001 Actions instead of Conditions: if ( firewallready() ) then ( openfirewall(); if ( packetready() ) then ( sendpacket() ) else ( Reply.Answer.Message = "Packet not ready" ); closefirewall() ) else ( Reply.Answer.Message = "Firewall not ready" ) If one wants to refer to an object tree returned by different Proí cedures it is not recommended to use these Procedures in a single Condition. For example: if ( X = Call1(...) && Y = Call2(...) ) then (...) else (...) In this example several Actions are required in the else-part to determine whether the Condition became false due to the left or right operand of the AND-expression. Only then it is clear which objects are available. It is better to rewrite this Policy in the following more deterministic way: if( X = Call1(...) ) then ( if( Y = Call2(...) ) then(...) else(...) ) else(...) As holds for any programming language, the writer has the responsií bility to express his policies in a clear way, such that at releí vant places in the Policy, annotations can be added about the state of the evaluation. 3.5. Example Policy In this section we present a Driving Policy to deal with an AAA A. Taal et al. Expires: June 2002 [Page 18] Internet Draft Grammar for Policies in Generic AAA November 2001 Authentication request [OBJMSG]. A user issues an Authentication request containing the following objects: an Identity object and an AuthenticationData object [OBJMSG]. The AAA Server recognizes the request as an Authentication request and draws the corresponding Driving Policy from the PR. Assume, the AAA Server acts as a Key Distribution Center (KDC) for the Kerberos authentication protocol. The Kerberos protocol is comprised of three sub-protocols: a. Authentication Service Exchange; the client sends a Kerí beros Authentication Service Request (KRB_AS_REQ) b. Ticket-Granting Service Exchange; the client sends a Kerí beros Ticket-Granting Service Request (KRB_TGS_REQ) c. Client/Server Exchange; the client sends the server a Kerí beros Application Request (KRB_AP_REQ) The following policy might be a Driving Policy for an incoming Authentication request: if ( if( exists Request.AuthenticationData.Protocol.Name ) then( ) else ( Reply.Answer.Type = MISSING_DATA; Reply.Answer.Message = "Missing Protocol.Name" ) && if( Request.AuthenticationData.Protocol.Name == "Kerberos" ) then( ) else ( Reply = Authentication@131.211.32.73( Identity = Request.Identity, AuthenticationData = Request.AuthenticationData ) ) && if( exists Request.AuthenticationData.Protocol.MsgType ) then( ) else ( Reply.Answer.Type = MISSING_DATA; Reply.Answer.Message = "Missing Protocol.MsgType" ) && if( Request.AuthenticationData.Protocol.MsgType == KRB_AS_REQ ) A. Taal et al. Expires: June 2002 [Page 19] Internet Draft Grammar for Policies in Generic AAA November 2001 then( ) else ( Reply.Answer.Type = UNKNOWN_DATA; Reply.Answer.Message = "Unknown MsgType" ) ) then ( // Action 1 if ( exists Request.Identity.UserName && exists Request.AuthenticationData.ServerName && exists Request.AuthenticationData.PreAuthentication ) then ( // Action 1.1 KRBReply = authenticate( username = Request.Identity.UserName, servername = Request.AuthenticationData.ServerName, preauthentication = Request.AuthenticationData.PreAuthentication ); // Action 1.2 Reply.Answer.AuthenticationData.SessionKey = KRBReply.SessionKey; // Action 1.3 Reply.Answer.AuthenticationData.TGT = KRBReply.TGT ) else ( Reply.Answer.Type = MISSING_DATA; Reply.Answer.Message = "AuthenticationData incomplete" ); ... ) else ( ... ) In the above Driving Policy a Condition of four ANDed Policies is evaluated. Here we assume the following precondition: a proper AAA Authentication request containing an Identity object and an Authení ticationData object, furthermore, it is assumed that the last object contains a Protocol object. No additional assumptions are made about the contents of these objects. The first literal of the A. Taal et al. Expires: June 2002 [Page 20] Internet Draft Grammar for Policies in Generic AAA November 2001 Boolean expression (Condition), a Policy, checks if the Protocol object contains a variable called Name. If so the second literal will be evaluated because the then-part of the first literal has an empty ActionList. If not, the Actions in the else-part of the first literal are executed. These Actions add data to the Reply object [OBJMSG], by setting the variables Type and Message of the object Answer. The first Action might be interpreted as assigning a predeí fined integer called MISSING_DATA to the leaf node named Type of the Reply object. In case the first literal is found to be false, the Condition is false and the Actions in the else-part of the Driving Policy are executed. The second literal has a reference to a remote policy (PolicyRef) as an Action. This Action is executed if the authentication protocol requested differs from the Kerberos protocol. It entails an AAA Request issued to another AAA Server (131.211.32.73). Information about what kind of AAA Request has to be send, is provided by the name-part of the PolicyRef, which equals one of the message types defined. Two arguments are passed to the policy reference, the Identity and the AuthenticationData object form the original request. The assignment indicates that the response from the remote reference becomes the reply to the request. Both remaining literals are similar to the first literal. One Action is given in the then-part of the Driving Policy. This Action is a Policy which Condition checks for the existence of some variables (objects), like UserName, ServerName, and PreAuthenticaí tion. As this Action is a Policy, it has an ActionList of its own. Of the three Actions in this list, the first might be interpreted as a call to an ASM. The remaining Actions transport objects from the return tree to the Reply. 3.6. Pushing Policies Pushing policies between AAA Servers might pose some problems. We've identified a couple of situations where it is not desirable to push policies: 1. 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 coní tradicting each other (which is a fault of the local adminisí trators). A pushed policy doesn't have knowledge about the local policies. 2. A pushed policy can contain `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. A. Taal et al. Expires: June 2002 [Page 21] Internet Draft Grammar for Policies in Generic AAA November 2001 3. An AAA Server might run on a machine with limited computí ing power and/or bandwidth The machine could easily be swamped when policies are pushed from other machines. That said, a policy can be pushed by storing it in a Request object. A special message type should be used to indicate that a pushed policy has to be processed. The Driving Policy for this request can decide whether the pushed policy is accepted or not. If it is, the object containing the pushed policy could be passed to a special FunctionCall which in turn extracts the policy and feeds it to the policy evaluation mechanism of the AAA Server. This way, no special provisions are needed in the policy language itself to allow pushed policies. References [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Vollí brecht, "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, January 2001 [AAAGEN] C. de Laat, J. Vollbrecht and D. Spence, "Structure of a Generic AAA Server", draft-irtf-aaaarch-generic-struct-00.txt, February 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 Faculty of Science, Informatics Institute University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257590 Fax: +31 20 5257490 Email: taal@science.uva.nl Guus Sliepen Physics and Astronomy department Utrecht University A. Taal et al. Expires: June 2002 [Page 22] Internet Draft Grammar for Policies in Generic AAA November 2001 Princetonplein 5 3584 CC Utrecht The Netherlands Phone: +31 30 2537724 Fax: +31 30 2537555 Email: G.Sliepen@phys.uu.nl Armijn Hemel Institute of Information and Computing Sciences Utrecht University Padualaan 14 3584 CH Utrecht The Netherlands Email: aehemel@cs.uu.nl Cees de Laat Faculty of Science, Informatics Institute University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257590 Fax: +31 20 5257490 Email: delaat@science.uva.nl A. Taal et al. Expires: June 2002 [Page 23]