view Side-By-Side changes
INTERNET TaalINTERNET DRAFT G.Sliepen Category:SliepenCategory: Informational C.T.A.M. de LaatJulySeptember 2004 A grammar for Policies in a Generic AAA Environment<draft-irtf-aaaarch-generic-policy-05.txt> Status<draft-irtf-aaaarch-generic-policy-06.txt>Status of this MemoThis document is an Internet-DraftBy submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, andisany of which I become aware will be disclosed, infull conformanceaccordance withall provisions of Section 10 ofRFC2026.3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This memo describes work in progress within the AAAARCH Research Group. Comments are welcome and should be submitted to aaaarch@fokus.gmd.de. Distribution of this memo isunlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. A.unlimited.A. Taal et al. Expires:December 2004March 2005 [Page1] Internet1]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 Abstract In this document the concept of a so-called Driving Policy is presented. A Driving Policy determines the behavior of an AAA server (Authentication, Authorization, Accounting) when it is confronted with a specific AAA message. The first part of this document defines the role of a Driving Policy and how it fits into the AAA concept. From the model presented results a restricted grammar for Driving Policies with as few predefined terms as possible. The main task of a Driving Policy is to describe which pre-conditions have to be checked before actions, needed to fulfill an incoming AAA request, are delegated to Application Specific Modules, and how to deal with the post-conditions of these actions. In the second part the grammar for Driving Policies is presented accompanied by the necessary remarks about thesemantics. Tablesemantics.Table of Contents Status of this Memo . . . . . . . . . . . . . . . . . . . . . . 1 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 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' . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . 14 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6. Other policy languages . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .17 A.17A. Taal et al. Expires:December 2004March 2005 [Page2] Internet2]Internet Draft Grammar for Policies in Generic AAAJuly 2004 1.September 20041. Introduction Before discussing the role of a Driving Policy and how it fits into the AAA concept, an abstract view of a generic AAA environment [RFC2903] is presented in fig. 1. Only those components are presented that are necessary to support the discussion in this draft. +----+ +---+ +---+ |User|<======>|AAA|<===================================>|AAA| +----+ +---+<========= =========>+---+ /\ /\ \\ // /\ /\ || || || || || || || \/ || || || \/ \/ +--+ || || \/ +--+ +---+ |PR| || || +---+ |PR| |ASM| +--+ \/ \/ |ASM| +--+ +---+ +---+ +---+ +---+ |AAA|<=========>|AAA| +---+ +---+ /\ /\ /\ /\ || || || || || \/ || \/ \/ +--+ \/ +--+ +---+ |PR| +---+ |PR| |ASM| +--+ |ASM| +--+ +---+ +---+ Figure 1. The abstract view of a generic AAA environment 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 the AAA server understands (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.theA. Taal et al. Expires:December 2004March 2005 [Page3] Internet3]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 +-------------+ |+-------------+ +| AAA request | +-------------+ /\ / \ / \ / \ / \ / Generic \ / AAA \ /--------------\ +----------------+ +------+ |+----------------+ |+------+ +| Driving Policy | +| ASM | +----------------+ +------+ Figure 2. The AAA server ASMs hide the low-level details of the service requested. This allows for compact as possible DrivingPolicies. 2.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/Reply +-----------------+ <<include>> ----- <============> | Satisfy Request |============ | +-----------------+ || / \ || \/ User || <<include>> +-----------------------+ || | Lookup Driving Policy | \/ +-----------------------+ +-------------------------+ ===>| Evaluate Driving Policy |<========== || +-------------------------+ \\ <<extend>> || <<extend>> /\ \\ policy requires || policy requires || <<extend>> \\ authorization || accounting || policy requires \\ +------------+ || authentication \\ | Perform | +-------------------+ +----------------+ | Accounting | | Authenticate User | | Authorize User | +------------+ +-------------------+ +----------------+ Figure 3. Use Case diagram for an AAArequest A.requestA. Taal et al. Expires:December 2004March 2005 [Page4] Internet4]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 We define a single Actor, called User, as an entity that speaks an 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. 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' Between the Use Case 'Satisfy Request' and 'Lookup Driving Policy', as well as between 'Satisfy request' and 'Evaluate Driving Policy', there exists an include relationship. The functionality described in 'Satisfy request' always includes the functionality of 'Lookup Driving Policy' and 'Evaluate Driving Policy'. Those last two Use Cases are mandatory for 'Satisfy request'. The extend relationships are interpreted as conditional include relationships. The Use Cases 'Authenticate User' and 'Authorize User', and 'Perform Accounting' are only performed if some internal condition in the Use Case 'Evaluate Driving Policy' requiresit. 2.1.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 corresponding 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 server understands (section4). A.4).A. Taal et al. Expires:December 2004March 2005 [Page5] Internet5]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 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.(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 RBE to keep track of all the decisionprocesses. 2.4.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 onlyper-perĪ formed if the Driving Policy under evaluation requires it. When that is the case, the request must contain information about necessary policy variables with respect to authentication. Furthermore, the request may contain a certificate or password, his proof of identity. In order to be sure the User is the one he says he is, his proof of identity needs to beverified. 2.5.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 theUser. A.User.A. Taal et al. Expires:December 2004March 2005 [Page6] Internet6]Internet Draft Grammar for Policies in Generic AAAJuly 2004 2.6.September 20042.6. The Use Case 'Perform Accounting' Accounting is the collection of all the data about resource consumption. 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. The Use Cases 2.4, 2.5 and 2.6 concerning authentication, authorization and accounting are complex Use Cases in the sense that special ASMs are involved rather than generic AAA functions. In general these special ASMs will apply their own policies(language). 3.(language).3. DrivingPolicies 3.1.Policies3.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. 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. Besides some simple arithmetic all complex tasks are delegated to the generic AAA server or to an ASM. If communication with other AAA servers is required, a call to a generic function or ASM is made. In case a request contains a reference to a policy, this task is also delegated to a generic function or to an ASM. This means that the grammar does not need to provide for a policy reference or a call to a remote AAA server. As a consequence the grammar can be kept as concise aspossible. 3.2.possible.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 A.BoolExprA. Taal et al. Expires:December 2004March 2005 [Page7] Internet7]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 BoolExpr ::= Bool | Var | {Var "="}? Procedure | ComputedBoolean | UnaryBooleanOperator BoolExpr | "(" BoolExpr BinaryBooleanOperator BoolExpr ")" 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}*}? A.Action}*}?A. Taal et al. Expires:December 2004March 2005 [Page8] Internet8]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 Action ::= Var "=" Bool | Var "=" String | Var "=" ComputedBoolean | Var "=" NonBooleanExpr | Procedure | DrivingPolicy Var ::= {Source "::" }? Source {"." Source}* Source ::= Identifier ProcedureName ::= Identifier "::" Identifier "." 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 executed 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 thegrammar. 3.2.1.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. Theintroduction A.introductionA. Taal et al. Expires:December 2004March 2005 [Page9] Internet9]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 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 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 '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(...) A.(...)A. Taal et al. Expires:December 2004March 2005 [Page10] Internet10]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 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 || Pol ) then( a0 ) else ( a1 ) with Pol: if( B ) then( b0 ) else ( b1 ). Adopting the C convention this Driving Policy is equivalent to if( A ) then( a0 ) else ( if( B ) then( b0 ; a0 ) else( b1 ; a1 )) 3.2.2.)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 a string with 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 Var refers to an empty object tree if the head of the corresponding dot-structure does not begin with "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. A relative simple implementation of a RBE suffices if we restrict ourselves to Vars representing a leaf of an object tree, i.e. a primitive value. In case Vars representing an internal node are desired, Vars refer to objects to be created by the RBE, and some additional remarks about the semantics of assignments with variables should be made. 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 objecttree. A.tree.A. Taal et al. Expires:December 2004March 2005 [Page11] Internet11]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 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 with the information where the value referenced can be retrieved or stored. The object tree of the request always starts with 'Request::', whereas the object tree of the corresponding reply begins with 'Reply::'. Consider the following example of an AAA request in XML: <Request type="Service" > <ServiceData> <SwitchData> <Source>192.168.1.5</Source> <Destination>192.168.1.6</Destination> <Bandwidth>500</Bandwidth> <StartTime>12:45</StartTime> <Duration>45</Duration> </SwitchData> </ServiceData> </Request> A variable 'Request::ServiceData.SwitchData.Bandwidth' indicates a unique path to the node <Bandwidth>. The following assignments are syntactically correct: Request::AuthenticationData.UserID = "John" ABC::Count = Reply::Answer.Value but it is not clear what the semantic meaning is. It depends on the implementation of the RBE. The first assignment might be implemented such that the request variable is changed and subsequent use of the same variable will apply the modified value, or the RBE might raise an error in case request variables are interpreted as read-only variables. The second assignment might fail in case the reply variable has not been assigned a value in a previous action, or in case the RBE interprets reply variables as write-onlyvariables. 3.2.3.variables.3.2.3. Procedures A Procedure may be interpreted as a function call to an Application Specific Module (procedure name starts with "ASM::"), or as a call to a library function the Generic AAA server is equippedwith A.withA. Taal et al. Expires:December 2004March 2005 [Page12] Internet12]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 (procedure name starts with "AAA::"). If an assignment is made the return value is accessible in the remaining policy. From section 3.2.2 it follows that the return value is a primitive value, like an int, float or string. 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. 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 (section 4) should provide for request/reply objects in order to support referencing remote policies. Such a reference might also be implemented as a call to a generic function or to anASM. 3.2.4.ASM.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 beexecuted. 3.3.executed.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 within a specified time 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. In any case it is necessary to define a special Reply to inform the requester that policy evaluation has aborted. The detection of erroneous situations, including timeout of ASMcalls, A.calls,A. Taal et al. Expires:December 2004March 2005 [Page13] Internet13]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 is the responsibility of the RBE. In general the AAA server should be notified too about errors, as the AAA server supervises all activities. There are several possibilities 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 = "Bandwidth too large" ) ) else( Reply::Answer.Message = "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 functioncall. 4.call.4. Data Objects and Message Types This section describes the need for a specification of the message types and the top level objects to be carried in a future AAA protocol. As the number of different AAA servers is almost unlimited, the same holds for the number of different Request/Reply pairs. An AAA server providing bandwidth has little in common with an AAA server for the ordering of a pizza. A new technique like WSDL (Web Services Description Language) opens the possibility to cope with the expected diversity in AAA Request/Reply pairs. WDSL [WSDL] can be used to specify in detail information about the service an AAA server delivers such as the type of data it requires (Request) and the type of data it produces (Reply). Applying WSDL, the specification of the message types and the top level objects can be limited to those messages needed for the intercommunication between AAA servers. Such a list of message types should certainlycontain: A.contain:A. Taal et al. Expires:December 2004March 2005 [Page14] Internet14]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 a) Authorization Request/Reply b) Authentication Request/Reply c) Policy Request/Reply d) Policy Evaluation Request/Reply e) Error Reply For instance, a Policy Request is sent to an AAA server to obtain a remote policy. It should contain a Policy Reference object. The corresponding Reply should contain a Policy dataobject. 5.object.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. The correspinding Driving Policy asks for the authentication of the requester before the service will be delivered The Request: <?xml version="1.0" encoding="UTF-8"?> <Request version="0.1" type="Service" > <AuthenticationData> <Identity>Joe</Identity> <Password>aaa</Password> </AuthenticationData> <ServiceData> <SwitchData> <Source>192.168.1.5</Source> <Destination>192.168.1.6</Destination> <Bandwidth>500</Bandwidth> <StartTime>12:45</StartTime> <Duration>45</Duration> </SwitchData> </ServiceData> </Request> The corresponding Reply: <?xml version="1.0" encoding="UTF-8"?> <Reply version="0.1" type="Service" > <Answer><Message></Message></Answer> </Reply> The AAA server recognizes the request as an Service request and draws the corresponding Driving Policy from thePR: A.PR:A. Taal et al. Expires:December 2004March 2005 [Page15] Internet15]Internet Draft Grammar for Policies in Generic AAAJulySeptember 2004 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 theUser. A.User.A. Taal et al. Expires:December 2004March 2005 [Page16] Internet16]Internet Draft Grammar for Policies in Generic AAAJuly 2004 6.September 20046. Other policy languages The language according to the presented grammar describes policies that might be implemented in several policy languages. However the concept of a Driving Policy presented in this paper (fig. 2) justifies the definition of a special restricted grammar for Driving Policies. The concept chosen allows for a policy language with as few predefined terms as possible as the tasks an AAA server has to perform are mainly delegated to Application Specific Modules or generic AAAfunctions. Referencesfunctions.References [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J.Voll-VollĪ brecht, "Generic AAA Architecture", RFC 2903, August 2000 [WSDL]http://www.w3.org/TR/wsdl Authors'http://www.w3.org/TR/wsdlAuthors' 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.delaat@science.uva.nlA. Taal et al. Expires:DecemberMarch 2005 [Page 17]Internet Draft Grammar for Policies in Generic AAA September 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. A. Taal et al. Expires: March 2005 [Page17]18] ----