AAAARCH Research Group A. Taal INTERNET DRAFT G. Sliepen Category: Experimental A.E. Hemel C.T.A.M. de Laat June 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: December 2001 [Page 1] Internet Draft Grammar for Policies in Generic AAA June 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 goal is to setup an environment where the AAA Servers from the various domains can work together in order to satisfy requests from users for services that cross those domains. In order to allow distributed policies in a generic AAA environé ment, a policy must be able to reference another policy. This means that parts of a distributed policy may be stored and evaluated at a remote AAA server. A reference to a local policy, i.e. a policy stored in the same AAA server as the referencing policy, should be interchangeable with the policy referenced. To facilitate this feaé ture the policy language must allow recursion. Table of Contents Status of this Memo . . . . . . . . . . . . . . . . . . . . . . 1 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Table of Contents . . . . . . . . . . . . . . . . . . . . . . . 2 1. AAA environment . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . 5 2.1. The Use Case 'Satisfy request' . . . . . . . . . . . . . . 6 2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . . 6 2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . . 6 2.4. The Use Case 'Authenticate user' . . . . . . . . . . . . . 7 2.5. The Use Case 'Authorize User' . . . . . . . . . . . . . . 7 3. Policies . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Formal model . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.2. Constants and variables . . . . . . . . . . . . . . . . 14 3.2.3. Actions . . . . . . . . . . . . . . . . . . . . . . . . 14 3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4. Construction guidelines . . . . . . . . . . . . . . . . . 17 3.5. Example Policy . . . . . . . . . . . . . . . . . . . . . . 19 3.6. Pushing Policies . . . . . . . . . . . . . . . . . . . . . 20 References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 21 A. Taal et al. Expires: December 2001 [Page 2] Internet Draft Grammar for Policies in Generic AAA June 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 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 Reposé itory (PR) where Policies reside. 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. Some parts of a policy might not be able to be handled by a generic component or the policy language itself. In that case the AAA Server resorts to an Application Specific Modé ule (ASM) for that part. A. Taal et al. Expires: December 2001 [Page 3] Internet Draft Grammar for Policies in Generic AAA June 2001 +-------------------------------------all-sessions-+ |+---------------------------one-session-+ | || +---+ +-------------+ +-+ +---+ | | 1 || |PD |- |RBE / Control| |R| -|PD | | | 1 =========>|aaa|-----|Module / Req.|--|B|--|aaa|===================> || | |- |Manager | | | -| | | | || +---+ +-------------+ +-+ +---+ | | || | | | | | | | | || | / | | \ | | | || +---+ / | | \ +---+ | | || |SEC| | | \ \ |SEC| | | || | | +---+ | +--+ \ | | | +----+ | || +---+ |API| \ |PD| \ +---+ | |Sess| | || |asm| \ +--+ \ | |Man.| | || +---+ +--+ \ -------------| | | || /|\ |PD| \ | | | | || / | \ +--+ ----- | +----+ | || / |2 \ \ \ | | |+------/---|---\--------\--------\------+ | | / | \ \ \ | +-----/-----|-----\--------\--------\--------------+ | | | | | +---+ +---+ +---+ +-----+ +-----+ |ASM| |ASM| |ASM| |DB | |DB | | | | | | | |event| |pol. |----(Driving Policy) +---+ +---+ +---+ |log | |repos| /|\ /|\5 /|\ +-----+ +-----+ ... ... ... Figure 2. The abstract view of a generic AAA Server [AAAGEN] A more detailed view of the AAA Server itself reveals the Driving Policy. The Driving Policy specifies the behavior of the AAA Server for a certain request. For example, the Driving Policy in a shop AAA Server would define the shop functions. If ASMs are involved, 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 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: December 2001 [Page 4] Internet Draft Grammar for Policies in Generic AAA June 2001 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 3. 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. 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-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 five Use Cases: - 'Satisfy request' A. Taal et al. Expires: December 2001 [Page 5] Internet Draft Grammar for Policies in Generic AAA June 2001 - '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. Every request is foré warded 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. 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). 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 A. Taal et al. Expires: December 2001 [Page 6] Internet Draft Grammar for Policies in Generic AAA June 2001 conditions the user is not authorized to push. The request may contain Attribute Value Pairs (AVP), which values have to be subé stituted for free variables occurring in the policy. Some free variables in the policy may only be solved by a specific applicaé tion. 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 polé icy. 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 proé cess 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 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. 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 believe are necé essary for any future model. A. Taal et al. Expires: December 2001 [Page 7] Internet Draft Grammar for Policies in Generic AAA June 2001 There are several reasons to come with a formal model for a 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 grammar influé ence 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 request and response objects [OBJMSG] must be suited to accommodate the necesé sary 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 content 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): Policy ::= "if" Condition "then" "(" ActionList ")" "else" "(" ActionList ")" A. Taal et al. Expires: December 2001 [Page 8] Internet Draft Grammar for Policies in Generic AAA June 2001 Condition ::= Literal | UnaryBooleanOperator Condition | "(" Condition BinaryBooleanOperator Condition ")" UnaryBooleanOperator ::= "NOT" | "!" BinaryBooleanOperator ::= "AND" | "OR" | "&&" | "||" Literal ::= Bool | BoolVar | ComputedBoolean | Policy | {Source "="}? BooleanProcedure BooleanProcedure ::= PolicyRef | ASMCall ASMCall ::= ASMName "(" AVPList ")" ASMName ::= Identifier ActionList ::= {Action {"," Action}*}? Action ::= "AVP" Name "=" Param | {Source "="}? BooleanProcedure Param ::= Condition | IntExpr | FloatExpr | StringExpr ComputedBoolean ::= IntExpr ComparisonOperator IntExpr | FloatExpr ComparisonOperator FloatExpr | StringExpr ComparisonOperator StringExpr | "exists" Source "." Name ComparisonOperator ::= "==" | ">" | ">=" | "<" | "<=" | "!=" IntExpr ::= "(" IntExpr BinaryArithmeticOperator IntExpr ")" | UnaryArithmeticOperator IntExpr | IntVar A. Taal et al. Expires: December 2001 [Page 9] Internet Draft Grammar for Policies in Generic AAA June 2001 | Int FloatExpr ::= "(" FloatExpr BinaryArithmeticOperator FloatExpr ")" | UnaryArithmeticOperator FloatExpr | FloatVar | Float StringExpr ::= "(" StringExpr "+" StringExpr ")" | StringVar | String UnaryArithmeticOperator ::= "-" BinaryArithmeticOperator ::= "+" | "-" | "/" | "*" | "%" BoolVar ::= "BOOL" Source "." Name IntVar ::= "INT" Source "." Name FloatVar ::= "FLOAT" Source "." Name StringVar ::= "STRING" Source "." Name Name ::= Identifier Source ::= Identifier PolicyRef ::= PolicyName "@" Hostname "(" AVPList ")" AVPList ::= {AVP {"," AVP}*}? AVP ::= Source "=" Param PolicyName ::= 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 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 A. Taal et al. Expires: December 2001 [Page 10] Internet Draft Grammar for Policies in Generic AAA June 2001 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 sucé cessfully executed. In all other situations, the state of the Polé icy is undetermined due to the occurrence of an error. As the gramé mar does not provide for exception handling, the only reasonable choice is to stop the evaluation of the Policy after error occuré rence. An important concept of the model is the result of a Polé icy, which is defined as a list that contains at least one element. The first element of this list is the result of the evaluation of the Condition (i.e., true or false). All additional elements of the list are attribute-value pairs (AVPs). Those AVPs can be added to the list by a special Action indicated by the key word "AVP" (e.g. AVP Permission=true). This concept of a list is also attached to the components PolicyRef and ASMCall. 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 ASMCall can be interpreted as a procedure call to an Application Specific Module (ASM), or more general a call of a library function the AAA server is equipped with. With respect to the result their is no difference between a Policy, a PolicyRef and an ASMCall. As these three components have a Boolean value they can be part of a Condition. Furthermore, these three components can also be applied as Actions. A consequence of policy references is the need of communication between AAA Servers during policy evaluation. A future AAA protoé col should provide for request/response objects in order to support referencing remote policies [OBJMSG]. Policies can be nested in both Conditions as well as Actions. A Policy in the then-part and else-part of a Policy gives the possié bility to express a more deterministic policy, while allowing a Policy within a Condition introduces the notion of `attaching Actions to subexpressions of a Condition'. 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 A. Taal et al. Expires: December 2001 [Page 11] Internet Draft Grammar for Policies in Generic AAA June 2001 words the if-statement is said to be deterministic. Conditions are to be evaluated from left to right. For an OR expression it holds that the right operand is not evaluated if the left operand evalué ates 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 ) AND if ( C2 ) then ( A21 ) else ( A22 ) ) then ( A00 ) else ( A01 ) Policy 2: if( C1 ) then( if( C2 ) then( A11, A21, A00 ) else( A11, A22, A01 ) ) else ( A12, A01 ) A Condition, or Boolean formula, is composed of five different types of operands (Literals): Bool, BoolVar, ComputedBoolean, Polé icy and BooleanProcedure. An operand of type Bool is just the Boolean value true or false. The type BoolVar refers to an AVP, which has a Boolean value ( see below ). A ComputedBoolean is a comparison between a left and right hand expression. Both expressions must be of the same type. Three types of expression are defined: an expression of integers (Inté Expr), an expression of floating point numbers (FloatExpr), and an expression of strings (StringExpr). An important aspect of an expression is that it can contain varié ables (IntVar, FloatVar, StringVar). In propositional calculus, a ComputedBoolean is a just a predicate with free variables. A varié able has three components: a Type, a Source, and a Name. The Type component specifies whether the variable is an integer (INT), a floating point number (FLOAT) or a character string (STRING). Both the Name and Source component provides the RBE (Rule Based Engine) with the information where the value of that variable can be retrieved. All variables are attribute-value pairs (AVPs), whether specified in the AAA-request, or as an AVP returned from a BooleanProcedure. A. Taal et al. Expires: December 2001 [Page 12] Internet Draft Grammar for Policies in Generic AAA June 2001 The two types of BooleanProcedure are equivalent in the sense that they all result in a list, which first value (or head) contains true or false. All other members of the list are attribute-value pairs. These two BooleanProcedures are a PolicyRef and an ASMCall. 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, ASMCall, may be interpreted as a function call to an Applicaé tion Specific Module (ASM), or as a call to a library function. In order to access the AVPs in a list returned form a BooleanProceé dure, one has to assign a Source-name to it. Only one Source-name is reserved, "Request", which refers to AVPs in the Request. An example of an `Authentication Policy' illustrates this mechanism. Herein the password supplied in the request has to be compared with the password of the user stored in the authentication database: if ( Query = getPassword(STRING Request.UserID && STRING Request.PassW == STRING Query.PassW ) then (...) else (...) The ASM function getPassword() retrieves the password corresponding to the username that has been supplied as a parameter. This parameé ter refers to an AVP called "UserID" in the Request and is of the type STRING. As a result, getPassword() returns a list from which it can be inferred whether the call was successful or not (first member of the list). By making the assignment "Query=getPassé word(...)" , the AVPs in the return list can be referred to. This is done in the right hand side of the AND. A BooleanProcedure can be applied in a Condition without an assigné ment. In that case the AVPs in the return list are not accessible. Only the Boolean (true or false) result of the ASM procedure or remotely evaluated Policy is used. A useful feature is the operator "exists" in combination with an AVP as a ComputedBoolean. This allows to check if a certain AVP exists in a return list or Request: if ( exists Request.Bandwidth AND INT Request.Bandwidth >= 10 ) then (...) A. Taal et al. Expires: December 2001 [Page 13] Internet Draft Grammar for Policies in Generic AAA June 2001 else (...) 3.2.2. Constants and variables The grammar allows four types of constants and variables: BOOL, INT, FLOAT and STRING. The machine types corresponding to these types are: bool, 32 bit signed int, 32 bit IEEE floating point and 8-bit ISO-8859-1 string. This allows type checking by the RBE, e.g. an AVP of type FLOAT specified in a Policy will generate an error if the AVP in the list referred is of type STRING. 3.2.3. 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. 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 (...) AND if packetready() then( sendpacket() ) else ( closefirewall() ) ) then (...) else (...) A very special Action is the one which adds an AVP to the return A. Taal et al. Expires: December 2001 [Page 14] Internet Draft Grammar for Policies in Generic AAA June 2001 list. Wherever this Action occurs in a Policy, the AVP is added to the return list of the outer most Policy. In the example below the Actions 'AVP Error="Firewall not ready" ' and 'AVP Error="Packet not ready"' result in the addition of the corresponding AVP to the result list of the outer policy. if( if firewallready() then( openfirewall() ) else( AVP Error="Firewall not ready" ) AND if packetready() then( sendpacket() ) else ( closefirewall(), AVP Error="Packet not ready" ) ) then (...) else (...) If on the contrary we only add AVPs to the return list of the inner most Policy, assignments should be made in order to make these AVPs available to the rest of the Policy, otherwise the return AVPs of the inner most Policy would be lost. 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 AVPs that are missing. An ASM function, 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. AVPs might contain values of a different type than given in the Policy. 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 desirable that the evaluation stops after the first error. However in the following example it might be desirable to continue the evaluation, whether errors occur or not: A. Taal et al. Expires: December 2001 [Page 15] Internet Draft Grammar for Policies in Generic AAA June 2001 ( ( A or B ) or ( C or D ) ) Let this be a scenario where A, B and C generate errors but are ignored, and D is evaluated true without any errors. This Condié tion might still make sense. Take for example a broker which has to distribute tasks to a pool of servers, some of which might not be online. The consideration whether to stop or continue after an error also holds for ActionLists. Suppose an administrator writes down the following policy: if ( firewallready() AND packetready() ) then ( openfirewall(), sendpacket(), closefirewall() ) else (...) If it happens that the first Action, openfirewall(), is successful but the second Action, sendpacket(), fails, it is desirable to coné tinue with the third Action, closefirewall(). If on the contrary the first Action fails, it is desirable to stop. So, when an error which is not caught by whatever construction in the Policy occurs, the AAA Server either has to ignore the error and continue or abort evaluation. Both choices have advantages in some situations, and disadvantages in others. The AAA Server cané not 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 occuré ring 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 policy administrator can make sure that the policies are coné structed in such a way that errors do not result in an undesirable situation. This is shown in the next section. A. Taal et al. Expires: December 2001 [Page 16] Internet Draft Grammar for Policies in Generic AAA June 2001 3.4. Construction guidelines An example: +---+ | 3 | +---+ / / +---+ +---+ | 1 |------| 2 | +---+ +---+ User AAA \ \ +---+ | 4 | +---+ Suppose a User at location 1 wants bandwidth to start a video stream at time t=T from location 3 to location 4. The User issues a request, say at t=0 to reserve the necessary bandwidth. This request is sent to the AAA Server at location "2". There the request is recognized as a request for bandwidth reservation. The User, the application acting on behalf of the real user, has the a priori knowledge which parameters are needed by the AAA Server to fulfill his request. Those parameters are added to the request as attribute-value pairs, say: - Bandwidth = 100 - Source = "3" - Destination = "4" - StartTime = T0 - StopTime = T1 The Driving Policy applied by the AAA Server may look like: if reserveBandwidth(STRING Request.Source, STRING Request.Destination, INT Request.Bandwidth, FLOAT Request.StartTime, FLOAT Request.StopTime) then ( AVP status="Request for bandwidth has been satisfied" ) else (...) The reservation of the bandwidth is typically a task to be A. Taal et al. Expires: December 2001 [Page 17] Internet Draft Grammar for Policies in Generic AAA June 2001 performed by an ASM. As the reservation of bandwidth between devices is a complicated process, different errors can occur. Howé ever, the grammar allows a nested if-then-else structure by which the occurrence of errors can be reduced, for instance by checking the preconditions: if ( exists Request.Bandwith && INT Request.Bandwidth >= 10 ) then ( if ( INT Request.Bandwidth <= 500 ) then (...) else ( AVP error="Requested bandwidth too large" ) ) else ( AVP error="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 ( AVP error="Firewall not ready" ) AND if packetready() then ( sendpacket() ) else ( closefirewall(), AVP error="Packet not ready" ) ) then ( closefirewall() ) else (...) Note the fact that the ASM function closefirewall() has to appear twice in this policy, and the fact that the second subexpression (where the packet is sent if it is ready), now has the responsibilé ity of closing the firewall if there is a problem. This means that the second subexpression cannot be easily replaced by a RemotePolé icy (it can, but it loses the benefit of modularity). Now take this functionally equivalent Policy, but now the nesting is done inside Actions: if firewallready() then ( openfirewall(), if packetready() then ( sendpacket() ) A. Taal et al. Expires: December 2001 [Page 18] Internet Draft Grammar for Policies in Generic AAA June 2001 else ( AVP error="Packet not ready" ), closefirewall() ) else ( AVP error="Firewall not ready" ) If one wants to refer to AVPs returned by different BooleanProceé dures it is not recommended to use these BooleanProcedures in a single Condition. For example: if ( x = call1(...) AND 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. Only then it is clear which AVPs 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 Policy for network access. A user issues a request for network access with the following AVPs: UserID="myName" PassW="@#!a" Furthermore the request contains information from which the AAA server can infer which Policy is needed. Suppose this Policy is the one given below. The Condition of this Policy is a reference to a remote Policy, "getProfile", at an AAA server called "user.server.org". Two AVPs from the request are passed as argué ments, "UserID" and "PassW". By assigning a Source "UserProfile" to this reference, an AVP "GroupID" from the return list is A. Taal et al. Expires: December 2001 [Page 19] Internet Draft Grammar for Policies in Generic AAA June 2001 available inside this Policy. If this call to a remote policy is successful, the two Actions of the ActionList are executed. First an reference to a locally stored Policy. This Action takes as argument an AVP called "GroupID" from the return list "UserProé file". As a result an AVP "Permission" is available in the return list "AppRules". The second Action, an inline Policy, checks if this AVP has a Boolean value true. If so, an IP-address is assigned which is passed as an argument in an call to setup a Session. if UserProfile=getProfile@user.server.org( userid=STRING Request.UserID, passw=STRING Request.PassW) then ( AppRules=getAppRules@localhost( groupame=STRING UserProfile.GroupID), if BOOL AppRules.Permission then ( if IP=assignIPAddress() then ( if Session=sessionSetup( STRING Request.UserID, STRING IP.Address) then ( AVP SessionID = STRING Session.ID, AVP IPAddress = STRING IP.Address ) else ( releaseIPAddress(Address=STRING IP.Address), AVP Error = "Unable to setup session" ) ) else ( AVP Error = "No IP Address" ) ) else ( AVP Error = "Permission Denied" ) ) else ( AVP Error = "User Profile Not Found" ) 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. 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 A. Taal et al. Expires: December 2001 [Page 20] Internet Draft Grammar for Policies in Generic AAA June 2001 local administrators). A pushed policy doesn't have knowledge about the local policies. The second 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 third situation is when we put an 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. 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, 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 Princetonplein 5 3584 CC Utrecht The Netherlands Phone: +31 30 2537556 Fax: +31 30 2537555 Email: A.Taal@phys.uu.nl A. Taal et al. Expires: December 2001 [Page 21] Internet Draft Grammar for Policies in Generic AAA June 2001 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 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: December 2001 [Page 22] --