AAAARCH Research Group A. Taal INTERNET DRAFT G. Sliepen Category: Informational C.T.A.M. de Laat March 2002 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: September 2002 [Page 1] Internet Draft Grammar for Policies in Generic AAA March 2002 Abstract In this document a formal language is presented to describe poli- cies in the context of a generic AAA environment. We confine the discussion to so called Driving Policies. A Driving Policy deter- mines the behavior of an AAA Server when it is confronted with a specific message type of the AAA protocol. These Driving Policies should facilitate AAA Servers from various domains to work together in order to satisfy requests from users for services that cross those domains. Therefore, a Driving Policy must be able to reference other policies, since Service Level Agreements with other domains are implemented as policies. Other important features of a Driving Policy are the possibility to call 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' . . . . . . . . . . 5 2.4. The Use Case 'Authenticate user' . . . . . . . . . . . . . 6 2.5. The Use Case 'Authorize User' . . . . . . . . . . . . . . 6 2.6. The Use Case 'Perform Accounting' . . . . . . . . . . . . . .6 3. Driving 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 . . . . . . . . . . . . . . . . . . . . 13 3.2.5. Actions . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4. Data Objects and Message Types . . . . . . . . . . . . . . . 15 5. Example Policy . . . . . . . . . . . . . . . . . . . . . . . 15 6. Ponder policy language . . . . . . . . . . . . . . . . . . . .18 References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 A. Taal et al. Expires: September 2002 [Page 2] Internet Draft Grammar for Policies in Generic AAA March 2002 1. AAA environment +----+ +---+ +---+ |User|<=======>|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 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. The Driving Policy specifies the behavior of the AAA Server for a certain request. For each message type of a future AAA protocol (section 4) there exists a corresponding Driving Policy that is evaluated. These Driving Policies are stored in the Policy Repository (PR). 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. For special tasks the AAA Server (RBE) resorts to generic functions or to so called Application Specific Modules (ASMs). Because Driving Policies can refer to local policies and to ASMs for complex taks, the contents of the Policy Repository and the ASMs determine the behavior of the AAA Server. A change of the 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. A. Taal et al. Expires: September 2002 [Page 3] Internet Draft Grammar for Policies in Generic AAA March 2002 2. Use Case Diagram +-+ +-+ | request +-----------------+ <> ----- <=========> | Satisfy request |============ | +-----------------+ || / \ || \/ User || <> +-----------------------+ || | Lookup Driving Policy | \/ +-----------------------+ +-------------------------+ ===>| Evaluate Driving Policy |<========== || +-------------------------+ \\ <> || <> /\ \\ policy requires || policy requires || <> \\ authorization || accounting || policy requires \\ +------------+ || authentication \\ | Perform | +-------------------+ +----------------+ | Accounting | | Authenticate User | | Authorize User | +------------+ +-------------------+ +----------------+ Figure 2. Use Case diagram for an AAA request We will consider the role of a Driving Policy in response to a so called AAA 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 - Actors: User - Precondition: none In total we distinguish six Use Cases: - 'Satisfy request' - 'Lookup Driving Policy' - 'Evaluate Driving Policy' - 'Authenticate user' - 'Authorize user' - 'Perform Accounting' A. Taal et al. Expires: September 2002 [Page 4] Internet Draft Grammar for Policies in Generic AAA March 2002 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', and æPerform AccountingÆ 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 this policy and constructs the corres- ponding response. A more detailed view of this Use Case would be the set of Use Cases associated with the different message types of the AAA protocol. 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. As there exists a one-to-one ad onto relationship between AAA requests and Driving Policies, it clear to the AAA Server which Driving Policy it has to retrieve. Any request will result in the lookup of the corresponding 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 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. The request may contain objects (primitive data types ) to be sub- stituted for free variables occurring in the Driving Policy. The RBE substitutes everything at the proper place into the policy. After the RBE 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 all the decision processes. A. Taal et al. Expires: September 2002 [Page 5] Internet Draft Grammar for Policies in Generic AAA March 2002 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). Authentication and authorization is only performed if the 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. 2.6. The Use Case 'Perform Accounting' Accounting is the collection of all the data about resource con- sumption. Intermediate accounting or accounting indication informs the User about currently used resources. The AAA Server must provide the information about which Resource Managers need to be consulted. Resource Managers resorts to Meters that capture data about resource consumption in the network. 3. Driving 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 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 Driving Policy. In this document a grammar is 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. For instance components like an ASM (Application Specific Module) provide the real functionality of an AAA Server, and therefore there will certainly be provisions for that in the grammar. The type of constructions defined in the A. Taal et al. Expires: September 2002 [Page 6] Internet Draft Grammar for Policies in Generic AAA March 2002 grammar influence the ways in which the ASMs will be accessed, and therefore the way the whole AAA environment will react. Driving Policies might be distributed, i.e. it may reference a Policy residing at another AAA Server. In that case communication between AAA Servers is involved during policy evaluation. The request and response objects [section ??] 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 to allow pushed policies in the AAA environment. An AAA Server or even an application acting on behalf of a user should be allowed to present policies in a request. Obviously a standard protocol or language must exist for those policies so that the parties involved agree upon the contents. 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 the elements, which will most likely be part of an official AAA policy grammar. The grammar is kept as concise as possible, so that policies according to this grammar turn out to be a subset of existing policy languages. In section ?? a short outline is presented how these policies can be described by the policy language Ponder [PONDER]. We also present this grammar to facilitate the discussion about AAA policies, and to document this language in order to explain the results of a possible simulation 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 | Var | ComputedBoolean | {Var "="}? Procedure | Policy | UnaryBooleanOperator BoolExpr | "(" BoolExpr BinaryBooleanOperator BoolExpr ")" A. Taal et al. Expires: September 2002 [Page 7] Internet Draft Grammar for Policies in Generic AAA March 2002 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 BinaryArithmeticOperator NonBooleanExpr ")" UnaryArithmeticOperator ::= "-" BinaryArithmeticOperator ::= "+" | "-" | "/" | "*" | "%" A. Taal et al. Expires: September 2002 [Page 8] Internet Draft Grammar for Policies in Generic AAA March 2002 Var ::= Source {"." Source}* Source ::= Identifier PolicyName ::= Identifier FunctionName ::= Identifier Hostname ::= String 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 (Driving Policy) can be viewed as an if-then-else con- struction. The Condition (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 (ActionList). 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 successfully executed. A Policy is said to be false if and only if the Condition is false, and the Actions in the else-part are successfully 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 subexpressions of a 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 nesting. Two other components of the model that can have a truth value are a PolicyRef and a FunctionCall. 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). It should be clear that local or remore policies refered to in a Policy are not subjected to the grammar presented, they may be A. Taal et al. Expires: September 2002 [Page 9] Internet Draft Grammar for Policies in Generic AAA March 2002 expressed in other policy languages. The component FunctionCall can be interpreted as a function call to an Application Specific Module (ASM), or more general a call of a generic library function the AAA server is equipped with. An important concept is the result of a PolicyRef and a FunctionCall. With respect to the result their is no difference 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 avoids any ambiguity, without the need to define a precedence rule for the logical AND- ("&&") and OR-operator ("||"). It is desirable to define how a Condition is evaluated, or in other words the if-statement is said to be deterministic. Here we follow the C language, which also guarantees that `&&' and `||' are evaluated left to right. For an OR-expression it holds that the right operand is not evaluated 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 Condition can not be evaluated in parallel. From parallel evaluation follows that the requester should be satisfied with any result making the Condition true or false. Consider an OR-expression composed of references to remote AAA Servers. Parallel evaluation means parallel requests to the remote AAA Servers. There is no guarantee that the AAA Server with the first positive response will be the same any time the Driving Policy is evaluated. In order to give an administrator more freedom to specify how a Condition should be evaluated, the grammar should be extended by concurrency operators. According to the above definition the following two Policies are equivalent: 1) if( if ( C1 ) then ( A11 ) else ( A12 ) && if ( C2 ) then ( A21 ) else ( A22 ) ) then ( A00 ) else ( A01 ) 2) if( C1 ) then( if( C2 ) then( A11 ; A21 ; A00 ) else( A11 ; A22 ; A01 ) ) else ( A12 ; A01 ) A. Taal et al. Expires: September 2002 [Page 10] Internet Draft Grammar for Policies in Generic AAA March 2002 A Condition, or Boolean expression, is composed of six different types of operands (literals): Bool, Var, ComputedBoolean, Procedure, Policy, and BoolExpr. 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 dot-structure 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 correspon- ding 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 (section 4). The other type, FunctionCall, may be interpreted as a function call to an Application Specific Module (ASM), 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. The only reason a different syntax is applied for PolicyRef and FunctionCall, is to indicate that different APIs (protocols) are involved for PolicyRefs and FunctionCalls, respectively. An example of an `Authentication Policy' illustrates some of the concepts dealt with above: if( Query = getPassword( userid = Request.UserID ) && Request.PassW == Query.PassW ) then (...) else (...) Herein, the Condition compares the password supplied in the request with the password of the user stored in the authentication data- base. The ASM function getPassword() retrieves the password cor- responding to the username that has been supplied as an argument. This argument refers to a variable called "UserID" in the Request. 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. Taal et al. Expires: September 2002 [Page 11] Internet Draft Grammar for Policies in Generic AAA March 2002 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 constants 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 results in an abortion of the evaluation. 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 an int, float or string value. A reference to an internal node means that the Var refers to an object, i.e. an sub-tree of the object tree starting at that specific internal node. Take for instance the Authentication Request/Reply (section 4) Request: Reply: Identity Answer AuthenticationData Suppose the Identity object in the request contains a string called UserID. This member of the Request may be represented as a Var (variable) with the dot-structure: Request.Identity.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 we propose the following semantics of assignments with variables. 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 refers to an existent object tree, i.e. a non-empty object tree. 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. A. Taal et al. Expires: September 2002 [Page 12] Internet Draft Grammar for Policies in Generic AAA March 2002 2) The left-hand side is an existent object tree whereas the right-hand side is an empty 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 existent object tree. This is the declaration 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. 3.2.4. Policy references There is a difference between a policy reference (PolicyRef) to a local policy and one to a remote policy. A reference to a remote policy 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. 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. If the PolicyReference refers to a local policy, the PolicyName indicates which policy should be retrieved from the Policy Repository. 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 propose the following semantics with respect to Actions. The requirements mentioned below are arbitrary in the sense that another policy language might impose different requirements. They have to defined however, for reasons mentioned above. 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. A. Taal et al. Expires: September 2002 [Page 13] Internet Draft Grammar for Policies in Generic AAA March 2002 Take for example the Policy below. In this example, it is clear that the Action openfirewall() of the first Policy HAS to have successfully 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 (...) && if( packetready() ) then( sendpacket() ) else ( closefirewall() ) ) then (...) else (...). The introduction of concurrency operators in the grammar opens the possibility to indicate in which order Actions should be executed. 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 FunctionCall, for example getPassword(), might generate an error, because for example the password is not found in the database, or because the database is off-line. Actions can also generate errors, for instance openfirewall() may fail. Since we allow arithmetic expressions, another type of error might be caused by a division by zero. 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 (previous section) openfirewall() fails, then continuing the evaluation of the Condition will certainly make sendpacket() fail as well. In this example it is desirable that the evaluation stops after the first error. So, when an error that is not caught by whatever construction in the Policy occurs, the RBE either has to ignore the error and continue or abort evaluation. As exception handling is not part of the grammar, the most safe strategy is to abort evaluation. The administrator can make sure that the Policies are constructed in such a way that the occurrence of error states are limited. This might be done by checking the input for Procedures if it meets A. Taal et al. Expires: September 2002 [Page 14] Internet Draft Grammar for Policies in Generic AAA March 2002 the precondition. Take for instance a Service request for band- width that contains an object ServiceData. A precondition for the FunctionCall to the appropriate ASM, might be that the requested bandwidth is at least 10 and at most 100. Then a Driving Policy may look like: if( exists Request.ServiceData.Bandwith && Request.ServiceData.Bandwidth >= 10 ) then ( if( Request. ServiceData.Bandwidth <= 500 ) then(...) else(Reply.Answer.Message = "Requested bandwidth too large" ) ) else( Reply.Answer.Message = "Requested bandwidth too small" ) 4. Data Objects and Message Types This section describes the need for a specification of the message types and of top level objects to be carried in a future AAA protocol. For each message type there should be a corresponding Driving Policy. Message types occur as a Request Reply couple. Such a list of message types should certainly contain: a) Service Request/Reply b) Authorization Request/Reply c) Authentication Request/Reply d) Policy Request/Reply e) Policy Evaluation Request/Reply For instance, a Policy Request is sent to an AAA Server to obtain a remote policy. It would contain a data object, Policy Reference. The corresponding Reply would contain a Policy data object. Once these message types and data object are defined, UML Use Cases can be defined, describing by which an AAA server may be used by one of the AAA Actors. As a result pre- and postconditions can be abstracted to guide the construction of the corresponding Driving Policies. 5. Example Policy In this section we present a Driving Policy to deal with an AAA Authentication request. A user issues an Authentication request containing the following objects: an Identity object and an AuthenticationData object. The AAA server recognizes the request A. Taal et al. Expires: September 2002 [Page 15] Internet Draft Grammar for Policies in Generic AAA March 2002 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 subprotocols: a) Authentication Service Exchange; the client sends a Kerberos Authentication Service Request (KRB_AS_REQ ) b) Ticket-Granting Service Exchange; the client sends a Kerberos Ticket-Granting Service Request (KRB_TGS_REQ ) c) Client/Server Exchange; the client sends the server a Kerberos 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 ) 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 ) A. Taal et al. Expires: September 2002 [Page 16] Internet Draft Grammar for Policies in Generic AAA March 2002 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 AuthenticationData object. Furthermore, it is assumed that the last object contains a Protocol object. About the contents of these objects no additional assumptions are made. The first literal of the 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, by setting the variables Type and Message of the object Answer. The first Action might be interpreted as assigning the variable Type to a predefined integer called MISSING_DATA. 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 A. Taal et al. Expires: September 2002 [Page 17] Internet Draft Grammar for Policies in Generic AAA March 2002 variables (objects), like UserName, ServerName, and PreAuthentication. 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. 6. Ponder policy language The language according to the presented grammar describes policies that can be implemented in for instance the Ponder policy language [PONDER]. Driving Policies should be implemented as obligation policies. In Ponder an obligation policy specifies the actions that must be performed by managers within the system when certain events occur. In the context of Driving Policies, an event is an AAA request issued by an user. In case of a nested Driving Policy, i.e. a Policy occurs as a literal in a Condition, or as an Action in an ActionList, a composite policy in Ponder should be used. The best choice is to use a role, a composite policy in which all the policies have the same subject. In our case the subject is an automated component called RBE. A role is also the choice if the Driving Policy is not nested, but has an non-empty ActionList in the then-part. Take for instance the following Driving Policy: if( Query = getPassWord( userid = Request.UserID ) && Request.PassW = Query.PassW ) then( action11( ) ; action12( ) ) else( action21( ) ; action22( ) ) In Ponder this may look like: type role authentication( Request req, Reply rep, Domain T ) { inst oblig authentication1 { on authentication_request( ); target T->select( t0, t11, t12 | true ); do t12.action11( )->t2.action12( ); when req.PassW = t0.getPassW( req.UserID ); } oblig authentication2 { on authentication_request( ); target T->select( t0, t21, t22 | true ); do t21.action21( )->t22.action22( ); when req.PassW <> t0.getPassW( req.UserID ); } } inst role a = authentication( /Request, /Reply, . . . ) @ /RBE A. Taal et al. Expires: September 2002 [Page 18] Internet Draft Grammar for Policies in Generic AAA March 2002 In general a nested Driving Policy can always be written as a set of simple Policies, i.e. a non-nested Policy with an empty ActionList in the then-part. For example, a Policy as a literal: if( A && if( B ) then( b11 ) else( b21 ) ) then( a11 ) else( a22 ) is equivalent to the following set of Policies: 1) if( A && B ) then( b11 ; a11 ) 2) if( A && !B ) then( b21 ; a21 ) 3) if( !A ) then( a21 ) Here it is assumed that the evaluation of a Condition is stopped as soon its truth-value is determined. Therefore, if A turns out to be false, B is not evaluated. Each of the simple Policies can be implemented as a separate obligation policy in a role, as outlined above. A. Taal et al. Expires: September 2002 [Page 19] Internet Draft Grammar for Policies in Generic AAA March 2002 References [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Voll- brecht, "Generic AAA Architecture", RFC 2903, August 2000 [PONDER] http://www-dse.doc.ic.ac.uk/research/policies/ponder.html 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 Princetonplein 5 3584 CC Utrecht The Netherlands Phone: +31 30 2537724 Fax: +31 30 2537555 Email: G.Sliepen@phys.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: September 2002 [Page 20]