AAAARCH Research Group A. Taal INTERNET DRAFT G. Sliepen Category: Informational C.T.A.M. de Laat Februari 2003 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: August 2003 [Page 1] Internet Draft Grammar for Policies in Generic AAA Februari 2003 Abstract In this document the concept of a so-called Driving Policy is pre- sented. A Driving Policy determines the behavior of an AAA server (Authentication, Authorization, Accounting) when it is confronted with a specific message type of the AAA protocol. The first part of this document defines the role of a Driving Policy and how it fits into the AAA concept. According to the model presented, the main task of a Driving Policy is to describe which pre-conditions have to be checked before the corresponding actions, needed to fulfill an incoming AAA request, can be called, and how to deal with the post-conditions of these actions. In the second part a grammar is proposed for these Driving Policies accompanied by the necessary comments about the semantics. 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' . . . . . . . . . . . 6 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 2.6. The Use Case 'Perform Accounting' . . . . . . . . . . . . . 6 3. Driving Policies . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Constants and variables . . . . . . . . . . . . . . . . 11 3.2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12 3.2.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . 13 3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Data Objects and Message Types . . . . . . . . . . . . . . . 13 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Other policy languages . . . . . . . . . . . . . . . . . . . 16 References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 A. Taal et al. Expires: August 2003 [Page 2] Internet Draft Grammar for Policies in Generic AAA Februari 2003 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 support the discussion in this draft. An AAA server may receive a request from an entity operating on a user's behalf. The request specifies 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. 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. For special tasks the AAA server (RBE) resorts to generic functions or to so called Application Specific Modules (ASMs). The contents of the Policy Repository and the ASMs determine the behavior of the AAA server (see fig.2). By changing the contents of the PR and the ASMs, the behavior of an AAA server can be adapted to other kinds of requests, i.e. its behavior can be modified. 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. The four components shown in fig.2 make it possible to adhere to the principles of Object Oriented design, like extendibility, reusability, and encapsulation. With respect to encapsulation, the A. Taal et al. Expires: August 2003 [Page 3] Internet Draft Grammar for Policies in Generic AAA Februari 2003 +-------------+ |+-------------+ +| AAA request | +-------------+ /\ / \ / \ / \ / \ / Generic \ / AAA \ /--------------\ +----------------+ +-------+ |+----------------+ | ASM |+ +| Driving Policy | +-------+| +----------------+ +-------+ Figure 2. The AAA server ASMs hide the low-level details of the service requested. This also allows for abstract as possible Driving Policies. 2. Use Case Diagram 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 an AAA request, fig. 3. As this is not the right document to fully describe these Use Cases, only a concise description is presented. +-+ +-+ | 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 3. Use Case diagram for an AAA request A. Taal et al. Expires: August 2003 [Page 4] Internet Draft Grammar for Policies in Generic AAA Februari 2003 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 association between the Actor and this Use Case is bi-directional This 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' 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 reveal a set of Use Cases associated with the different message types of the AAA protocol (section 4). A. Taal et al. Expires: August 2003 [Page 5] Internet Draft Grammar for Policies in Generic AAA Februari 2003 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. There exists a one-to-one and onto relationship between AAA requests and Driving Policies, therefore, it is 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' This task is delegated to the Rule Based Engine. The request may contain objects (primitive data types) to be substituted for free variables occurring in the Driving Policy. The RBE substitutes everything at the proper place into the policy. If generic functions or ASMs are referenced in the Driving Policy, the RBE makes the call with the right arguments. The RBE decides whether the policy is false, true or undecided yet. This Use Case does not excludes the evaluation of other policies, as ASMs might have their own policies. It is the responsibility of the AAA server to keep track of all the decision processes. 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 A. Taal et al. Expires: August 2003 [Page 6] Internet Draft Grammar for Policies in Generic AAA Februari 2003 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. 3, the behavior of an AAA server is policy driven with respect to a request. In this section we present a grammar for Driving Policies. There is a tight relationship between the grammar and the architecture of an AAA server. The Driving Polices together with the ASMs determine the specific functionality of an AAA server. As a consequence the grammar can be kept as concise as possible. The main functionality described by a Driving Policy is to check certain pre-conditions before calls to generic functions or ASMs are made, and to take actions according to the responses of these calls. Furthermore, it is supposed that if communication with other AAA servers is required, a call to a generic function is made. When a request contains a reference to a policy, this task is also delegated to a generic function. This means that the grammar does not need to provide for a policy reference or a call to a remote AAA server. 3.2. Grammar The grammar we propose here achieve its generic property through being minimal specified. We present this grammar to facilitate the discussion about AAA policies. The notation of the grammar below is in EBNF (Extended Backus Naur Formalism), terminal symbols are placed between double quotes: DrivingPolicy ::= "if" "(" Condition ")" "then" "(" ActionList ")" "else" "(" ActionList ")" Condition ::= BoolExpr BoolExpr ::= Bool | Var | {Var "="}? Procedure | ComputedBoolean | UnaryBooleanOperator BoolExpr | "(" BoolExpr BinaryBooleanOperator BoolExpr ")" A. Taal et al. Expires: August 2003 [Page 7] Internet Draft Grammar for Policies in Generic AAA Februari 2003 UnaryBooleanOperator ::= "!" BinaryBooleanOperator ::= "&&" | "||" Procedure ::= ProcedureName "(" ARGList ")" ARGList ::= {ARG {"," ARG}*}? ARG ::= Bool | String | ComputedBoolean | NonBooleanExpr ComputedBoolean ::= "(" NonBooleanExpr ComparisonOperator NonBooleanExpr ")" ComparisonOperator ::= "==" | ">" | ">=" | "<" | "<=" | "!=" NonBooleanExpr ::= Int | Float | Var | Procedure | UnaryArithmeticOperator NonBooleanExpr | "(" NonBooleanExpr BinaryArithmeticOperator NonBooleanExpr ")" UnaryArithmeticOperator ::= "-" BinaryArithmeticOperator ::= "+" | "-" | "/" | "*" | "%" | "&" | "|" ActionList ::= {Action {";" Action}*}? Action ::= Var "=" Bool | Var "=" String | Var "=" ComputedBoolean | Var "=" NonBooleanExpr | Procedure | DrivingPolicy Var ::= Source {"." Source}* A. Taal et al. Expires: August 2003 [Page 8] Internet Draft Grammar for Policies in Generic AAA Februari 2003 Source ::= Identifier ProcedureName ::= Identifier 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 Driving Policy can be viewed as an if-then-else structure. The Condition (if-part) yields a Boolean value, which may be the result of evaluating a larger expression. 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 Driving Policy we also attach a Boolean value. We define a Driving Policy to be true if and only if the Condition is true. A Driving Policy is said to be false if and only if the Condition is false. In all other situations, the state of the Driving Policy is undetermined due to the occurrence of an error (see section 3.3). Driving Policies can be nested in ActionLists. A Driving Policy in an ActionList gives the possibility to express a more deterministic policy. The component Procedure can be interpreted as a function call to an Application Specific Module (ASM), or more general a call to a generic library function the AAA server is equipped with. In the next sections we will explain the syntax of the grammar accompanied with remarks about the semantics of the 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 propose to 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 A. Taal et al. Expires: August 2003 [Page 9] Internet Draft Grammar for Policies in Generic AAA Februari 2003 parallel evaluation follows that the requester should be satisfied with any result making the Condition true or false, unless concurrency operators are introduced. A Condition, or Boolean expression, is composed of four different types of operands: Bool, Var, Procedure or ComputedBoolean. The use of a variable (Var), see below, implies that the value referenced can be interpreted as a Boolean value. The same holds for the return value of a Procedure when applied as a operand. A ComputedBoolean is a comparison between a left and right hand expression. An example of a Driving Policy for authentication illustrates some of the concepts dealt with above, as well as the semantics of Var and Procedure: if( ASM::Authenticator.checkPassword( Request::AuthenticationData.UserID, Request::AuthenticationData.Passwd ) ) then (...) else (...) Herein, the Condition consists of a Procedure, a call to an ASM with the name Authenticator, which has a public method checkPassword. Two arguments, both Vars, have to be passed. As the Vars start with the reserved word 'Request', the RBE knows that the values referenced are located in the Request. The dot- structure indicates the sub-tree of the Request. It is assumed that the Procedure returns a Boolean value. An alternative, wherein the Condition consists of a Computed Boolean, may look like: if( ( Request::AuthenticationData.Passwd == ASM::Authenticator.getPassword( Request::AuthenticationData.UserID ) ) ) then (...) else (...) As stated above, the if-statement is said to be deterministic, and as such there is no need to allow nesting of Driving Policies in a Condition. Take for instance the following nested Driving Policy: if( A || if( B ) then( b0 ) else ( b1 ) ) then( a0 ) else ( a1 ) Adopting the C convention this Driving Policy is equivalent to if( A ) then( a0 ) else ( if( B ) then( b0 ; a0 ) else( b1 ; a1 ) ) A. Taal et al. Expires: August 2003 [Page 10] Internet Draft Grammar for Policies in Generic AAA Februari 2003 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 a string and a floating point number results in an abortion of the evaluation. Variables (Vars) refer to a member of an object tree. The corresponding dot-structure indicates an unique path to a node of the object tree. We use the following definitions. A node of an object tree 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. 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 these definitions 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 the leaf C obtains the value of leaf E. 2) The left-hand side is an existent object tree whereas the right-hand side is an empty object tree. This means that 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. A variable, Var, is a dot-structure and provides the RBE (Rule Based Engine) with the information where the value referenced can be retrieved. The object tree of the request always starts with the reserved word 'Request', whereas the object tree of the corresponding reply begins with the reserved word 'Reply'. Consider the following example of an AAA request in XML: A. Taal et al. Expires: August 2003 [Page 11] Internet Draft Grammar for Policies in Generic AAA Februari 2003 192.168.1.5 192.168.1.6 500 12:45 45 A variable 'Request::ServiceData.SwitchData.Bandwidth' indicates a unique path to the node . 3.2.3. Procedures A Procedure may be interpreted as a function call to an Application Specific Module (ASM), or as a call to a library function the Generic AAA server is equipped with. If an assignment is made the return value is accessible in the remaining policy. If the Procedure is part of a Condition, it is supposed that the return value is a Boolean. In that case the truth-value of the Procedure is implicitly used to determine the truth-value of the Condition, whether or not an assignment is made. A Procedure is also used to reference to other policies. Referencing a local policy, stored in the local PR, might be implemented as a call to a generic function or to an ASM. If a remote policy is referenced, a policy stored in the PR of another AAA server, communication with another AAA server during policy evaluation is needed. A future AAA protocol should provide for request / reply objects in order to support referencing remote policies. Such a reference should be implemented as a call to a generic function. 3.2.4. 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. 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. The introduction of concurrency operators in the grammar may open the possibility to indicate in which order Actions should be executed. A. Taal et al. Expires: August 2003 [Page 12] Internet Draft Grammar for Policies in Generic AAA Februari 2003 3.3. Errors There are several circumstances under which errors can occur during the evaluation of policies or the execution of actions. The Driving Policy might refer to objects that are missing. A Procedure, for example getPassword(..), might fail to respond because the database is off-line. 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. Because the grammar does not provide for exception handling, the most safe strategy is to abort the evaluation of the policy after error occurrence. Error codes might be defined to inform the requester about the abortion of its request. There are several possibilities open to reduce the occurrence of errors. With respect to the failure of Procedures, the administrator can make sure that the Driving 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 the precondition. Take for instance a Service request for bandwidth that contains an object ServiceData. A precondition for the call to the appropriate ASM, might be that the requested bandwidth is at least 10 and at most 1000. Then a Driving Policy may look like: if( (Request::ServiceData.SwitchData.Bandwidth >= 10) ) then ( if( ( Request::ServiceData. SwitchData.Bandwidth <= 1000 ) ) then(...) else( Reply::Answer.Message = "Requested bandwidth too large" ) ) else( Reply::Answer.Message = "Requested bandwidth too small" ) If AAA requests are defined by XML, XML Schema's or DTDs might be used. An XML schema provides a means for defining the structure, content and the semantics of an XML document. This eliminates errors due to the bad contents of a request. The RBE might check division or incompatibilities in arithmetic expressions, as well as terminate policy evaluation after time out of a function call. 4. Data Objects and Message Types This section describes the need for a specification of the message types and of the 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. Taal et al. Expires: August 2003 [Page 13] Internet Draft Grammar for Policies in Generic AAA Februari 2003 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 objects are defined, UML Use Cases can be defined. As a result pre- and postconditions can be abstracted to guide the construction of the corresponding Driving Policies. 5. Example In this section we present a simple Driving Policy in XML to deal with an AAA request for bandwidth. A User issues an AAA request containing the following objects, an AuthenticationData object, and a ServiceData object: Joe aaa 192.168.1.5 192.168.1.6 500 12:45 45 The corresponding Reply: A. Taal et al. Expires: August 2003 [Page 14] Internet Draft Grammar for Policies in Generic AAA Februari 2003 The AAA server recognizes the request as an Service request and draws the corresponding Driving Policy from the PR: if ( ASM::Authenticator.Authenticate( Request::AuthenticationData.Identity, Request::AuthenticationData.Password ) ) then ( if ( ASM::RM.CheckConnection( Request::ServiceData.SwitchData.Source, Request::ServiceData.SwitchData.Destination ) ) then ( if ( (Request::ServiceData.SwitchData.Bandwidth <= 1000 ) ) then ( R1 = ASM::RM.BoD( Request::ServiceData.SwitchData.Source, Request::ServiceData.SwitchData.Destination, Request::ServiceData.SwitchData.Bandwidth, Request::ServiceData.SwitchData.StartTime, Request::ServiceData.SwitchData.Duration ) ; if( ( R1 < 0 ) ) then ( Reply::Answer.Message = "UNKNOWN failure occurred" ) else ( Reply::Answer.Message = "Request successful" ) ) else ( Reply::Answer.Message = "Bandwidth too small" ) ) else ( Reply::Answer.Message = "Bad source or destination" ) ) else ( Reply::Answer.Message = "Authentication failed" ) An Action like, Reply::Answer.Message = "Authentication failed", instructs the RBE to add a text node to the Reply that is returned to the User. A. Taal et al. Expires: August 2003 [Page 15] Internet Draft Grammar for Policies in Generic AAA Februari 2003 6. Other policy languages The language according to the presented grammar describes policies that can be implemented in several policy languages, e.g. Ponder [PONDER]. Due to the concept presented in this paper, Driving Polices expressed in another policy languages are expected to form a tiny sub-set of these languages. It is therefore justified to define a special grammar for Driving Policies. 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: August 2003 [Page 16] -- http://www.science.uva.nl/~delaat/