AAAARCH Research Group                                           A. Taal
INTERNET DRAFT                                                G. Sliepen
Category: Informational                                       A.E. Hemel
                                                        C.T.A.M. de Laat
                                                           November 2001




          A grammar for Policies in a Generic AAA Environment

               <draft-irtf-aaaarch-generic-policy-01.txt>



Status of this Memo

     This document is an Internet-Draft and is in full conformance with
     all provisions of Section 10 of RFC 2026.

     Internet-Drafts are working documents of the Internet Engineering
     Task Force (IETF), its areas, and its working groups. Note that
     other groups may also distribute working documents as Internet
     Drafts.

     Internet-Drafts are draft documents valid for a maximum of six
     months and may be updated, replaced, or obsoleted by other docuí
     ments at any time. It is inappropriate to use Internet-Drafts as
     reference material or to cite them other than as "work in
     progress."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

     This memo describes work in progress within the AAAARCH Research
     Group. Comments are welcome and should be submitted to
     aaaarch@fokus.gmd.de.

     Distribution of this memo is unlimited.


Copyright Notice

     Copyright (C) The Internet Society (2001). All Rights Reserved.




A. Taal et al.           Expires: June 2002                     [Page 1]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


Abstract

     In this document a formal model of a language to describe policies
     is presented in the context of a generic AAA environment. In such
     an environment, multiple domains or "kingdoms" are involved. Each
     domain has, in effect, Service Level Agreements (SLAs) with other
     domains. Those SLAs and other rules that may apply to a domain are
     implemented as policies in AAA Servers. The policies should facilií
     tate AAA Servers from the various domains to work together in order
     to Satisfy Requests from users for services that cross those
     domains. For complex services, not all knowledge can be packed into
     a single policy.  Therefore, a policy must be able to reference
     another policy. This might be a reference to a local policy, policy
     stored at the same AAA Server, as well as a reference to a remote
     policy, a policy stored at a remote AAA Server. Other important
     components of a policy are calls to generic functions the AAA
     Server is equipped with, and the possibility to delegate special
     tasks to so called Application Specific Modules.


Table of Contents

     Status of this Memo . . . . . . . . . . . . . . . . . . . . . .   1
     Copyright Notice  . . . . . . . . . . . . . . . . . . . . . . .   1
     Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . . .   2
     1. AAA environment  . . . . . . . . . . . . . . . . . . . . . .   3
     2. Use Case Diagram . . . . . . . . . . . . . . . . . . . . . .   4
     2.1. The Use Case 'Satisfy Request' . . . . . . . . . . . . . .   5
     2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . .   5
     2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . .   6
     2.4. The Use Case 'Authenticate User' . . . . . . . . . . . . .   6
     2.5. The Use Case 'Authorize User'  . . . . . . . . . . . . . .   6
     3. Policies . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . .   6
     3.2. Formal model . . . . . . . . . . . . . . . . . . . . . . .   7
     3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . .  10
     3.2.2. Constants and variables  . . . . . . . . . . . . . . . .  12
     3.2.3. Object trees . . . . . . . . . . . . . . . . . . . . . .  12
     3.2.4. Policy references  . . . . . . . . . . . . . . . . . . .  14
     3.2.5. Actions  . . . . . . . . . . . . . . . . . . . . . . . .  14
     3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . .  15
     3.4. Construction guidelines  . . . . . . . . . . . . . . . . .  16
     3.5. Example Policy . . . . . . . . . . . . . . . . . . . . . .  18
     3.6. Pushing Policies . . . . . . . . . . . . . . . . . . . . .  21
     References  . . . . . . . . . . . . . . . . . . . . . . . . . .  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . .  22




A. Taal et al.           Expires: June 2002                     [Page 2]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


1.  AAA environment

        +---+                                               +---+
        |AAA|<=============================================>|AAA|
        +---+<=============                       =========>+---+
       /\   /\             \\                   //         /\   /\
       ||   ||             ||                  ||          ||   ||
       ||   \/             ||                  ||          ||   \/
       \/   +--+           ||                  ||          \/   +--+
     +---+  |PR|           ||                  ||       +---+   |PR|
     |ASM|  +--+           \/                  \/       |ASM|   +--+
     +---+                +---+               +---+     +---+
                          |AAA|<=============>|AAA|
                          +---+               +---+
                         /\   /\              /\  /\
                         ||   ||              ||  ||
                         ||   \/              ||  \/
                         \/   +--+            \/  +--+
                       +---+  |PR|          +---+ |PR|
                       |ASM|  +--+          |ASM| +--+
                       +---+                +---+

          Figure 1. The abstract view of a generic AAA environment


     This section introduces an abstract view of a generic AAA environí
     ment [RFC2903], and what kind of components it consists of.  Only
     those components are presented that are necessary to illustrate the
     discussion in this draft.  An AAA Server may receive a request from
     an entity operating on a user's behalf.  The contents of the
     request contain what kind of service the user wants.  This request
     is evaluated by the Rule Based Engine (RBE) of the AAA Server where
     a Driving Policy resides that needs to be evaluated with respect to
     the request.  The Driving Policy specifies the behavior of the AAA
     Server for a certain request.  For each message type of a future
     AAA protocol [OBJMSG] there exists a corresponding Driving Policy
     that is evaluated.

     Whether the request will be accepted or rejected depends on the
     evaluation of the Driving Policy. In case the Driving Policy is
     part of a distributed policy, the AAA Server that receives the
     request has to communicate with other AAA Servers in order to fully
     evaluate the request. Complex and special tasks not possible or too
     cumbersome to express into the policy language are handled by
     generic components or by Application Specific Modules (ASMs).
     Because Driving Policies can refer to local policies and to ASMs
     for complex tasks, the contents of the Policy Repository (PR) and
     the ASMs determine the behavior of the AAA Server.  A change of the



A. Taal et al.           Expires: June 2002                     [Page 3]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     contents of the PR and the ASMs will result in a different AAA
     Server.  This feature should be dynamically supported to give an
     administrator the possibility to adjust the behavior of an AAA
     Server without the necessity to recompile the AAA Server code.


2.  Use Case Diagram

        +-+
        +-+
         |     request   +-----------------+      <<include>>
       ----- <=========> | Satisfy Request |============
         |               +-----------------+           ||
        / \                   ||                       \/
       User                   || <<include>>  +-----------------------+
                              \/              | Lookup Driving Policy |
              +-------------------------+     +-----------------------+
              | Evaluate Driving Policy *<====
              +-------------------------+     \\ <<extend>>
                           /\                  \\  policy requires
                <<extend>> ||                   \\ authorization
           policy requires ||                   ||
            authentication ||                   ||
                 +-------------------+    +----------------+
                 | Authenticate User |    | Authorize User |
                 +-------------------+    +----------------+

                  Figure 2. Use Case diagram for a request


     We will consider the role of a Driving Policy in response to a so
     called request.  To illustrate the scope of this policy in the
     generic AAA environment, we present a UML Use Case diagram for a
     future system of AAA Servers, fig. 2.  As this is not the right
     document to fully describe the Use Cases in fig. 2, only a concise
     description is presented.  We define a single Actor, called User,
     as an entity that speaks the AAA protocol.  This generalized user
     wants a request to be satisfied, the Use Case 'Satisfy Request'.

     The relationship between the Actor and this Use Case is a bi-direcí
     tional association.  It depicts the participation of the Actor in
     the Use Case.  This association is bi-directional because the User
     expects an answer to his request.

     At the highest level we have:

          - Use Case:      'Satisfy Request'
          - System:        Network of AAA Servers



A. Taal et al.           Expires: June 2002                     [Page 4]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


          - Actors:        User
          - Precondition:  none

     In total we distinguish five Use Cases:

          - 'Satisfy Request'
          - 'Lookup Driving Policy'
          - 'Evaluate Driving Policy'
          - 'Authenticate User'
          - 'Authorize User'

     Between the Use Case 'Satisfy Request' and 'Lookup Driving Policy',
     as well as between 'Satisfy Request' and 'Evaluate Driving Policy',
     there exists an include relationship.  The functionality described
     in 'Satisfy Request' always includes the functionality of 'Lookup
     Driving Policy' and 'Evaluate Driving Policy'.  Those last two Use
     Cases are mandatory for 'Satisfy Request'.  The extend relationí
     ships are interpreted as conditional include relationships.  The
     Use Cases 'Authenticate User' and 'Authorize User' are only perí
     formed if some internal condition in the Use Case 'Evaluate Driving
     Policy' requires it.


2.1.  The Use Case 'Satisfy Request'

     This Use Case will describe how an AAA Server deals with an AAA
     Request issued by a device acting on the behalf of a real user, and
     what answers towards the user can be given [OBJMSG].  Every request
     is forwarded to the AAA Server where the process to satisfy a
     request actually starts.  This AAA Server may manage a Policy
     Repository where the Driving Policy resides that needs evaluation.
     The AAA Server evaluates the policy and formulates a response.  It
     is of importance that the requester is well informed about the outí
     come of his request, especially when his request is rejected.


2.2.  The Use Case 'Lookup Driving Policy'

     The AAA Server must retrieve the Driving Policy that needs to be
     evaluated before the request can be satisfied.  Which policy to
     retrieve must be clear from the request.  Any request will result
     in a lookup for the Driving Policy in the local Policy Repository
     (PR).  As there exists a one-to-one mapping between AAA requests
     and Driving Policies, it is clear to the AAA Server which Driving
     Policy it has to retrieve.






A. Taal et al.           Expires: June 2002                     [Page 5]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


2.3.  The Use Case 'Evaluate Driving Policy'

     Policies can either be used in a stand-alone fashion or they can
     refer to other policies.  It is the task of the AAA Server to evalí
     uate all policies necessary.  This task is delegated to the Rule
     Based Engine (RBE, see fig. 2).  A complex situation occurs when a
     request contains a policy that is pushed by the user.  If this hapí
     pens it must be clear what logical relation this policy has with
     the stored Driving Policy, and whether this pushed policy contains
     conditions the user is not authorized to push.  It is the responsií
     bility of the AAA Server to keep track of the decision process.


2.4.  The Use Case 'Authenticate User'

     The authentication of the user is the process of verifying the
     proof of his identity.  Authentication of the user is only perí
     formed if the Driving Policy under evaluation requires it.  When
     that is the case, the request must contain information about necesí
     sary policy variables with respect to authentication.  Furthermore,
     the request may contain a certificate or password, his proof of
     identity.  In order to be sure the user is the one he says he is,
     his proof of identity needs to be verified.


2.5.  The Use Case 'Authorize User'

     An AAA Server performs authorization of a user's request, i.e.
     whether the user is allowed to obtain the requested service or
     resource(s).  Like authentication, authorization is only performed
     if a Driving Policy requires it.  It is not strictly necessary to
     perform authentication before authorization.  There are cases where
     the decision whether the request is authorized or not does not in
     any way depend on information about the user.


3.  Policies


3.1.  Introduction

     As can be derived from the Use Case diagram in fig. 2, the behavior
     of an AAA Server is policy driven with respect to an AAA Request.
     In order to expand the Use Case 'Evaluate Driving Policy', it is
     important to have a model for policies.  In this section we will
     outline such a model.  It will have components we believe are necí
     essary for any future model.  There are several reasons to come
     with a formal model for a policy.  In this document a grammar is



A. Taal et al.           Expires: June 2002                     [Page 6]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     presented.  As a Driving Policy determines the behavior of an AAA
     Server into a large extent, there is a tight relationship between
     the grammar and the architecture of an AAA Server.  The type of
     constructions defined in the grammar influence the ways in which
     the ASMs will be accessed, and therefore the way the whole AAA
     environment will react.

     Policies might be distributed, i.e. a policy may reference a policy
     residing at another AAA Server.  In that case communication between
     AAA Servers is involved during policy evaluation.  The AAA request
     and response objects [OBJMSG] must be suited to accommodate the
     necessary information for remote policy evaluation.  This shows an
     interdependence between the formal model and the object types of a
     future AAA protocol.

     Another important reason for a formal model of a policy is the need
     for pushed and pulled policies in the AAA environment.  An AAA
     Server or even an application acting on behalf of a user should be
     allowed to present or request policies in an AAA Request.  Obvií
     ously a standard protocol or language must exist so that the parí
     ties involved agree upon the contents of those policies.

     Since the AAA concept (architecture and protocol) is a complicated
     one, there exists a large need for simulation.  As the behavior of
     an AAA Server is policy driven, the contents of the Policy Reposií
     tory will be reflected in the outcome of a simulation.  The need
     for simulation comes from the hope to proof the decidability of
     policies in a distributed, generic AAA system.


3.2.  Formal model

     There can be many definitions of a policy grammar.  The grammar we
     propose here is NOT presented as an official AAA policy grammar.
     However, we present it to pinpoint some elements, which will most
     likely be part of an official AAA policy grammar.  We also present
     it to facilitate the discussion about AAA policies, and to document
     this language in order to explain the results of a possible simulaí
     tion of a generic AAA system.  The notation of the grammar below is
     in EBNF (Extended Backus Naur Formalism), terminal symbols are
     placed between double quotes:

          Policy ::= "if" "(" Condition ")" "then" "(" ActionList ")"
                                            "else" "(" ActionList ")"

          Condition ::= BoolExpr

          BoolExpr ::= Bool



A. Taal et al.           Expires: December 2001                 [Page 7]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


                     | Var
                     | ComputedBoolean
                     | {Var "="}? Procedure
                     | Policy
                     | UnaryBooleanOperator BoolExpr
                     | "(" BoolExpr BinaryBooleanOperator BoolExpr ")"

          UnaryBooleanOperator ::= "!"

          BinaryBooleanOperator ::= "&&" | "||"

          Procedure ::= PolicyRef | FunctionCall

          PolicyRef ::= PolicyName "@" Hostname "(" ARGList ")"

          FunctionCall ::= FunctionName "(" ARGList ")"

          ARGList ::= {ARG {"," ARG}*}?

          ARG ::= Var "=" Bool
                | Var "=" ComputedBoolean
                | Var "=" NonBooleanExpr
                | Var "=" Procedure

          ActionList ::= {Action {"," Action}*}?

          Action ::= Var "=" Bool
                   | Var "=" ComputedBoolean
                   | Var "=" NonBooleanExpr
                   | {Var "="}? Procedure
                   | Policy

          ComputedBoolean ::= NonBooleanExpr ComparisonOperator NonBooleanExpr
                            | "exists" Var

          ComparisonOperator ::= "=="
                               | ">"
                               | ">="
                               | "<"
                               | "<="
                               | "!="

          NonBooleanExpr ::= Int
                           | Float
                           | String
                           | Var
                           | UnaryArithmeticOperator NonBooleanExpr
                           | "(" NonBooleanExpr



A. Taal et al.           Expires: June 2002                     [Page 8]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


                                 BinaryArithmeticOperator NonBooleanExpr ")"

          UnaryArithmeticOperator ::= "-"

          BinaryArithmeticOperator ::= "+"
                                     | "-"
                                     | "/"
                                     | "*"
                                     | "%"

          Var ::= Source {"." Source}*

          Source ::= Identifier

          PolicyName   ::= Identifier
          FunctionName ::= Identifier

          Hostname ::= "[a-zA-Z0-9_.]+"

          Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*"
          String ::= "\"[^"\n]*\""
          Int ::= "-?[0-9]+"
          Float ::= "-?[0-9]+\.[0-9]*(E-?[0-9]+)?"
          Bool ::= "(true|false)"

     A Policy can be viewed as an if-then-else construction.  The Condií
     tion (if-part) yields a Boolean value, which may be the result of
     evaluating a larger expression.  Recursion of Conditions is allowed
     and opens the possibility to make complex policies.

     Both the then-part and the else-part consist of a list of Actions.
     Actions are tasks to be performed, and their execution is guarded
     by the Condition.  The Actions in the then-part are executed when
     the Condition is true, and the Actions in the else-part are exeí
     cuted when the Condition is false.  To a Policy we also attach a
     Boolean value.  We define a Policy to be true if and only if the
     Condition is true, and the Actions of the then-part are successí
     fully executed.  A Policy is said to be false if and only if the
     Condition is false, and the Actions in the else-part are successí
     fully executed.  In all other situations, the state of the Policy
     is undetermined due to the occurrence of an error. As the grammar
     does not provide for exception handling, the only reasonable choice
     is to stop the evaluation of the Policy after error occurrence.

     Policies can be nested in both Conditions as well as Actions. A
     Policy in an ActionList gives the possibility to express a more
     deterministic policy, while allowing a Policy within a Condition
     introduces the notion of `attaching Actions to sub-expressions of a



A. Taal et al.           Expires: June 2002                     [Page 9]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     Condition'.

     According to the above definition it follows that, whether a Policy
     is part of a Condition, or is used as an Action, its truth value
     determines the truth value of the Policy one level up in the nestí
     ing.

     Two other components of the model are a PolicyRef and a Functioní
     Call. A PolicyRef is a reference to a policy that may reside in the
     same Policy Repository (local policy) or may reside at another AAA
     Server (remote policy).  The component FunctionCall can be interí
     preted as a function call to an Application Specific Module (ASM),
     or more general a call of a library function the AAA Server might
     be equipped with. An important concept is the result of a PolicyRef
     and a FunctionCall. With respect to the result their is no differí
     ence between a PolicyRef and a FunctionCall. In general the result
     is an object tree, all members of the tree are accessible. The root
     object of the object tree contains the truth value of the PolicyRef
     or FunctionCall. As these components have a truth value, they can
     be part of a Condition or can be applied as an Action.

     In the next sections we will explain the syntax of the grammar
     accompanied with remarks about the semantics of that grammar.


3.2.1.  Conditions

     A Condition is defined as an arbitrary Boolean formula, i.e. we
     don't make the restriction to a formula in DNF (Disjunctive Normal
     Form) or CNF (Conjunctive Normal Form) notation.  The introduction
     of brackets ensures any ambiguity is avoided and, no precedence
     rules for operators or other constructions to resolve parsing coní
     flicts are needed. Apart from that, the conventions from the C laní
     guage are used. Conditions are to be evaluated from left to right.
     For an OR expression it holds that the right operand is not evaluí
     ated if the left operand evaluates to true. The same holds for the
     AND expression if the left operand evaluates to false. This also
     implies that different parts of a Policy can not be evaluated in
     parallel.

     According to this definition the following two Policies are equivaí
     lent:

     Policy 1:  if
                (
                  if ( C1 ) then ( A11 ) else ( A12 )
                  &&
                  if ( C2 ) then ( A21 ) else ( A22 )



A. Taal et al.           Expires: June 2002                    [Page 10]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


                )
                then ( A00 ) else ( A01 )

     Policy 2:  if( C1 )
                then
                (
                  A11;
                  if( C2 ) then( A21; A00 ) else( A22; A01 )
                )
                else ( A12; A01 )

     A Condition, or Boolean expression, is composed of five different
     types of operands (literals): Bool, Var, ComputedBoolean, Proceí
     dure, and Policy. An operand of type Bool, Var, ComputedBoolean, or
     Policy is just the Boolean value true or false.

     A ComputedBoolean is a comparison between a left and right hand
     expression. An important aspect of an expression is that it can
     contain variables (Var).

     A variable (Var) refers to a node (sub-tree) of an object tree. The
     corresponding dotted notation provides the RBE (Rule Based Engine)
     with the information where the sub-tree referenced can be
     retrieved. The object tree of the request always starts with the
     reserved word "Request", whereas the object tree of the correspondí
     ing reply begins with the reserved word "Reply".

     A reference to a policy (PolicyRef) opens the possibility to reuse
     local policies (policies in the same Policy Repository) as well as
     remote policies (policies residing in a Policy Repository managed
     by another AAA Server). This type may be interpreted as a Remote
     Procedure Call. A consequence of policy references is the need of
     communication between AAA Servers during policy evaluation. A
     future AAA protocol should provide for request/response objects in
     order to support referencing remote policies [OBJMSG]. The other
     type, FunctionCall, may be interpreted as a function call to an
     Application Specific Module, or as a call to a library function.
     Both Procedures, a PolicyRef and a FunctionCall, are equivalent in
     the sense that the result is an object tree. If an assignment is
     made all parts of this result tree are accessible in the remaining
     Policy. Whether or not an assignment is made, the truth value of
     the Procedure is implicitly used to determine the truth value of
     the Policy it is contained in.

     An example of an `Authentication Policy' illustrates some of the
     concepts dealt with above:

          if



A. Taal et al.           June 2002                             [Page 11]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


          (
            Query = getPassword(userid = Request.UserID)
            &&
            Request.PassW == Query.PassW
          )
          then (...)
          else (...)

     Herein the password supplied in the Request object is compared with
     the password of the user stored in the authentication database. The
     ASM function getPassword() retrieves the password corresponding to
     the username that has been supplied as an argument. This argument
     refers to a variable called "UserID" in the Request object.  By
     making the assignment "Query = getPassword(...)", the password in
     the return tree can be referred to. This is done in the right hand
     side of the Condition.

     A useful feature is the operator "exists" in combination with an
     object as a ComputedBoolean. This allows checking if a certain
     object exists in a return tree or request:

          if ( exists Request.Bandwidth && Request.Bandwidth >= 10 )
          then (...)
          else (...)


3.2.2.  Constants and variables

     The grammar allows the use of constants and variables, but like in
     other scripting languages (e.g. JavaScript) the grammar does not
     provide for type checking. Therefore, the use of variables and coní
     stants of different types in the same expression may result in an
     error state. For example the multiplication of two variables, one
     representing a string and the other representing a floating point
     number is not defined.


3.2.3.  Object trees

     As mentioned above, variables (Vars) refer to a member of an object
     tree. We use the following definitions. A node is a leaf if it has
     no children. All other nodes are internal nodes. If a Var refers to
     a leaf of an object tree, it refers to a primitive type, like a
     bool, int, float or string value. A reference to an internal node
     means that the Var refers to an object, i.e. a sub-tree of the
     object tree starting at that specific internal node.

     Take for instance the Authentication Request/Reply [OBJMSG]:



A. Taal et al.           Expires: June 2002                    [Page 12]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


          AAA Client                    AAA Server

          Request:               --->
          - Identity
          - AuthenticationData

                                 <---   Reply:
                                        - Answer

     Suppose the Identity object in the Request object contains a string
     called UserID.  This member of the Request object may be repreí
     sented as a Var (variable) with the dot-structure: Request.Idení
     tity.UserID. A Var refers to an empty object tree if the head of
     the corresponding dot-structure is not the reserved word "Request"
     or "Reply", and it is neither the head of a previously mentioned
     dot-structure. Such a Var may be interpreted as a leaf without a
     value. With this definition in mind the semantics of assignments
     with variables is the following. Consider the assignment of the
     form Var = Var with corresponding dot-structure A.B.C = D.E. Four
     different cases can be distinguished.

          1. The left and right hand side both refer to already defined
          object trees. Then the assignment means that all children of E
          are copied and become the children of C. All original children
          of C are lost. If C is a leaf but E is a node, then C becomes
          a node. In case both C and E are leaves, C remains a leaf but
          its value is changed to the value of E.

          2. The left hand side is an existing object tree whereas the
          right hand side is an empty (not yet declared) object tree.
          This means that the sub-tree of the tree at the left-hand side
          starting at node C is deleted. Node C becomes a leaf with no
          value.

          3. The left-hand side is an empty object tree whereas the
          right-hand side is an existing object tree. This is the declaí
          ration of a new object tree.

          4. Both sides of the assignment refer to an empty object tree.
          There is no need to define this as an error. As nothing has to
          be done, such an assignment might be ignored.

     It is important to notice that all assignments are assignments by
     value and NOT by reference. Assignment by reference would lead to
     undesirable effects. The assignment A.B.C = A.B would result in an
     object tree with node C pointing to itself.





A. Taal et al.           Expires: June 2002                    [Page 13]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


3.2.4.  Policy references

     There is a difference between a policy reference to a local policy
     and one to a remote policy. A reference to a remote policy (Polií
     cyRef) will initiate communication with another AAA Server. As all
     communication among AAA Servers will proceed via the AAA protocol,
     only predefined message types are used [OBJMSG]. Therefore, the
     name part (PolicyName) of the policy reference is limited to the
     name of one of these predefined message types.  This restriction
     does not hold for references to locally stored policies. Such a
     reference has only a restriction with respect to the host name
     used. Like Procedures, a reference to a local policy might be
     accompanied with arguments and returns an object tree. This raises
     the question if a difference in syntax is necessary. A FunctionCall
     and a PolicyRef to a local policy might be syntactically indistiní
     guishable, only different name spaces will reveal if one has to
     deal with a generic function call, a call to an ASM, or a reference
     to a local policy. In general PolicyRefs are not interchangeable
     with the policies they refer to.


3.2.5.  Actions

     In order to reduce unexpected effects to a minimum and make sure
     that different AAA Servers always exhibit the same behavior, we
     define the following semantics with respect to Actions.  The
     requirements mentioned below are arbitrary in the sense that
     another policy language might impose different requirements.

     All Actions in an ActionList must always be executed immediately
     after evaluating the corresponding Condition.  Immediately here
     means that Actions are executed in the order in which they appear
     in the ActionList, and an Action is only executed when the previous
     Action has finished successfully.  During execution of the Actions
     in the ActionList, policy evaluation is postponed.

     Take for example the Policy below.  In this example, it is clear
     that the Action openfirewall() of the first Policy HAS to have sucí
     cessfully finished BEFORE the Action sendpacket() from the second
     Policy is run.  Otherwise it might be possible that sendpacket()
     will fail (because the packet can't pass the firewall if it hasn't
     been opened yet).

          if
          (
            if ( firewallready() )
            then ( openfirewall() )
            else (...)



A. Taal et al.           Expires: June 2002                    [Page 14]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


            &&
            if ( packetready() )
            then( sendpacket() )
            else ( closefirewall() )
          )
          then (...) else (...)


3.3.  Errors

     There are several circumstances under which errors can occur during
     the evaluation of policies or the execution of actions.

     The Policy might refer to objects that are missing.  A Functioní
     Call, for example getPassword(), might generate an error, because
     the password is not found in the database, or because the database
     is off-line.  Actions can also generate errors, for instance opení
     firewall() may fail.  Since we allow arithmetic expressions,
     another type of error might be caused by a division by zero or
     other illegal operations.  As Vars might be of different types,
     incompatibilities might occur during evaluation of an expression,
     like a string multiplied by a float.

     Suppose that errors do not break or interfere with evaluation. If
     in the above example (in the previous section) openfirewall()
     fails, then continuing the evaluation of the Condition will cerí
     tainly make sendpacket() fail as well. In this example it is desirí
     able that the evaluation stops after the first error.  However
     there are examples where it make sense to continue after error
     occurrence. The consideration whether to stop or continue after an
     error also holds for ActionLists. So, when an error that is not
     caught by whatever construction in the Policy occurs, the AAA
     Server either has to ignore the error and continue or abort evaluaí
     tion. Both choices have advantages in some situations, and disadí
     vantages in others. The AAA Server cannot decide for itself what is
     best. A possible solution might be to introduce exception handling
     in the grammar, so that the policy administrator can tell the AAA
     Server how to react in case an error occurs.

     Again, an `arbitrary' choice has to be made in order to make all
     AAA Servers react in the same way to errors. Since errors occurring
     early in the Policy evaluation might trigger even more errors later
     on, possibly resulting in a disastrous cascade, we will require
     that AAA Servers abort evaluation of a Policy the moment an error
     occurs.

     The administrator can make sure that the Policies are constructed
     in such a way that errors do not result in an undesirable



A. Taal et al.           Expires: June 2002                    [Page 15]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     situation. This is shown in the next section.


3.4.  Construction guidelines

     An example:

                            +---+
                            | 3 |
                            +---+
                           /
                          /
          +---+      +---+
          | 1 |------| 2 |
          +---+      +---+
           User       AAA \
                           \
                            +---+
                            | 4 |
                            +---+

     Suppose a User at location "1" wants bandwidth to start a one hour
     long video stream at time t = T from location "3" to location "4".
     The User issues an AAA Request, say at t = 0 to reserve the necesí
     sary bandwidth.  This request is sent to the AAA Server at location
     "2" (a bandwidth broker).  There the request is recognized as a
     request for bandwidth reservation.  The User, or rather the applií
     cation acting on behalf of the real user, has the a priori knowlí
     edge which parameters are needed by the AAA Server to fulfill his
     request.  Those parameters are added to the Service request into
     the object ServiceData, say:

          ServiceData.Bandwidth = 100,
          ServiceData.Source = "3",
          ServiceData.Destination = "4",
          ServiceData.StartTime = T,
          ServiceData.StopTime = T + 3600

     A simple Driving Policy for this particular request at the AAA
     Server at location "2" may look like this:

          if
          (
            reserveBandwidth(source = Request.Source,
                             destination = Request.Destination,
                             bandwidth = Request.Bandwidth,
                             starttime = Request.StartTime,
                             duration = (Request.StopTime - Request.StartTime))



A. Taal et al.           Expires: June 2002                    [Page 16]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


          then
          (
            Reply.Answer.Message = "Request for bandwidth has been satisfied"
          )
          else (...)

     The reservation of the bandwidth is typically a task to be perí
     formed by an ASM.  As the reservation of bandwidth between devices
     is a complicated process, different errors can occur.  However, the
     grammar allows a nested if-then-else structure by which the occurí
     rence of errors can be reduced, for instance by checking the preí
     conditions:

          if ( exists Request.Bandwidth && Request.Bandwidth >= 10 )
          then
          (
            if ( Request.Bandwidth <= 500 )
            then (...)
            else ( Reply.Answer.Message = "Requested bandwidth too large" )
          )
          else ( Reply.Answer.Message = "Requested bandwidth too small" )

     The grammar also allows Policies nested inside Conditions.  There
     are advantages and disadvantages to this.  Take for example the
     following Policy which tries to send a packet through a firewall if
     both firewall and packet are ready:

          if
          ( if ( firewallready() )
            then ( openfirewall() )
            else ( Reply.Answer.Message = "Firewall not ready" )
            &&
            if ( packetready() )
            then ( sendpacket() )
            else
            (
              closefirewall();
              Reply.Answer.Message = "Packet not ready"
            )
          )
          then ( closefirewall() )
          else (...)

     Note the fact that the FunctionCall closefirewall() has to appear
     twice in this Policy, and the fact that the second sub-expression
     (where the packet is sent if it is ready) now has the responsibilí
     ity of closing the firewall if there is a problem.  Now take this
     functionally equivalent Policy, where the nesting is done inside



A. Taal et al.           Expires: June 2002                    [Page 17]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     Actions instead of Conditions:

          if ( firewallready() )
          then
          (
            openfirewall();

            if ( packetready() )
            then ( sendpacket() )
            else ( Reply.Answer.Message = "Packet not ready" );

            closefirewall()
          )
          else ( Reply.Answer.Message = "Firewall not ready" )

     If one wants to refer to an object tree returned by different Proí
     cedures it is not recommended to use these Procedures in a single
     Condition. For example:

          if ( X = Call1(...) && Y = Call2(...) )
          then (...)
          else (...)

     In this example several Actions are required in the else-part to
     determine whether the Condition became false due to the left or
     right operand of the AND-expression. Only then it is clear which
     objects are available. It is better to rewrite this Policy in the
     following more deterministic way:

          if( X = Call1(...) )
          then
          (
            if( Y = Call2(...) )
            then(...)
            else(...)
          )
          else(...)

     As holds for any programming language, the writer has the responsií
     bility to express his policies in a clear way, such that at releí
     vant places in the Policy, annotations can be added about the state
     of the evaluation.


3.5.  Example Policy


     In this section we present a Driving Policy to deal with an AAA



A. Taal et al.           Expires: June 2002                    [Page 18]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     Authentication request [OBJMSG]. A user issues an Authentication
     request containing the following objects: an Identity object and an
     AuthenticationData object [OBJMSG]. The AAA Server recognizes the
     request as an Authentication request and draws the corresponding
     Driving Policy from the PR.  Assume, the AAA Server acts as a Key
     Distribution Center (KDC) for the Kerberos authentication protocol.
     The Kerberos protocol is comprised of three sub-protocols:

          a. Authentication Service Exchange; the client sends a Kerí
          beros Authentication Service Request (KRB_AS_REQ)

          b. Ticket-Granting Service Exchange; the client sends a Kerí
          beros Ticket-Granting Service Request (KRB_TGS_REQ)

          c. Client/Server Exchange; the client sends the server a Kerí
          beros Application Request (KRB_AP_REQ)

     The following policy might be a Driving Policy for an incoming
     Authentication request:

          if
          (
              if( exists Request.AuthenticationData.Protocol.Name )
              then( )
              else
              (
                Reply.Answer.Type = MISSING_DATA;
                Reply.Answer.Message = "Missing Protocol.Name"
              )
            &&
              if( Request.AuthenticationData.Protocol.Name == "Kerberos" )
              then( )
              else
              (
                Reply = Authentication@131.211.32.73(
                          Identity = Request.Identity,
                          AuthenticationData = Request.AuthenticationData )
              )
            &&
              if( exists Request.AuthenticationData.Protocol.MsgType )
              then( )
              else
              (
                Reply.Answer.Type = MISSING_DATA;
                Reply.Answer.Message = "Missing Protocol.MsgType"
              )
            &&
              if( Request.AuthenticationData.Protocol.MsgType == KRB_AS_REQ )



A. Taal et al.           Expires: June 2002                    [Page 19]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


              then( )
              else
              (
                Reply.Answer.Type = UNKNOWN_DATA;
                Reply.Answer.Message = "Unknown MsgType"
              )
          )
          then
          (
            // Action 1
            if
            (
              exists Request.Identity.UserName
              &&
              exists Request.AuthenticationData.ServerName
              &&
              exists Request.AuthenticationData.PreAuthentication
            )
            then
            (
              // Action 1.1
              KRBReply = authenticate( username = Request.Identity.UserName,
                           servername = Request.AuthenticationData.ServerName,
                           preauthentication =
                             Request.AuthenticationData.PreAuthentication );

              // Action 1.2
              Reply.Answer.AuthenticationData.SessionKey = KRBReply.SessionKey;

              // Action 1.3
              Reply.Answer.AuthenticationData.TGT = KRBReply.TGT
            )
            else
            (
              Reply.Answer.Type = MISSING_DATA;
              Reply.Answer.Message = "AuthenticationData incomplete"
            );
            ...
          )
          else
          ( ... )

     In the above Driving Policy a Condition of four ANDed Policies is
     evaluated.  Here we assume the following precondition: a proper AAA
     Authentication request containing an Identity object and an Authení
     ticationData object, furthermore, it is assumed that the last
     object contains a Protocol object. No additional assumptions are
     made about the contents of these objects. The first literal of the



A. Taal et al.           Expires: June 2002                    [Page 20]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     Boolean expression (Condition), a Policy, checks if the Protocol
     object contains a variable called Name. If so the second literal
     will be evaluated because the then-part of the first literal has an
     empty ActionList. If not, the Actions in the else-part of the first
     literal are executed. These Actions add data to the Reply object
     [OBJMSG], by setting the variables Type and Message of the object
     Answer. The first Action might be interpreted as assigning a predeí
     fined integer called MISSING_DATA to the leaf node named Type of
     the Reply object. In case the first literal is found to be false,
     the Condition is false and the Actions in the else-part of the
     Driving Policy are executed. The second literal has a reference to
     a remote policy (PolicyRef) as an Action. This Action is executed
     if the authentication protocol requested differs from the Kerberos
     protocol. It entails an AAA Request issued to another AAA Server
     (131.211.32.73). Information about what kind of AAA Request has to
     be send, is provided by the name-part of the PolicyRef, which
     equals one of the message types defined. Two arguments are passed
     to the policy reference, the Identity and the AuthenticationData
     object form the original request. The assignment indicates that the
     response from the remote reference becomes the reply to the
     request. Both remaining literals are similar to the first literal.
     One Action is given in the then-part of the Driving Policy.  This
     Action is a Policy which Condition checks for the existence of some
     variables (objects), like UserName, ServerName, and PreAuthenticaí
     tion. As this Action is a Policy, it has an ActionList of its own.
     Of the three Actions in this list, the first might be interpreted
     as a call to an ASM. The remaining Actions transport objects from
     the return tree to the Reply.


3.6.  Pushing Policies

     Pushing policies between AAA Servers might pose some problems.
     We've identified a couple of situations where it is not desirable
     to push policies:

          1.  Policies might contradict each other, possibly resulting
          in unwanted behavior.  In the case of pushed policies the
          problem is more urgent than in the case of local policies coní
          tradicting each other (which is a fault of the local adminisí
          trators).  A pushed policy doesn't have knowledge about the
          local policies.

          2.  A pushed policy can contain `unwanted actions', resulting
          in a (possibly major) security risk.  This can result in the
          server wasting processing time, bandwidth and other resources,
          leaving it in such a state that it can't process other
          requests.



A. Taal et al.           Expires: June 2002                    [Page 21]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


          3.  An AAA Server might run on a machine with limited computí
          ing power and/or bandwidth The machine could easily be swamped
          when policies are pushed from other machines.

     That said, a policy can be pushed by storing it in a Request
     object.  A special message type should be used to indicate that a
     pushed policy has to be processed.  The Driving Policy for this
     request can decide whether the pushed policy is accepted or not.
     If it is, the object containing the pushed policy could be passed
     to a special FunctionCall which in turn extracts the policy and
     feeds it to the policy evaluation mechanism of the AAA Server.
     This way, no special provisions are needed in the policy language
     itself to allow pushed policies.


References

     [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Vollí
     brecht, "Generic AAA Architecture", RFC 2903, August 2000

     [OBJMSG] D. Spence, "Data Objects and Message Types in the Generic
     AAA Architecture", draft-spence-aaaarch-objmsg-00.txt, January 2001

     [AAAGEN] C. de Laat, J. Vollbrecht and D. Spence, "Structure of a
     Generic AAA Server", draft-irtf-aaaarch-generic-struct-00.txt,
     February 2001

     [AAAPOL] J. Salowey, G. Sliepen, A. Taal and D. Spence, "Policies
     in AAA", draft-irtf-aaaarch-aaa-pol-01.txt, February 2001


Authors' Addresses

     Arie Taal
     Faculty of Science, Informatics Institute
     University of Amsterdam
     Kruislaan 403
     1098 SJ Amsterdam
     The Netherlands

     Phone: +31 20 5257590
     Fax:   +31 20 5257490
     Email: taal@science.uva.nl


     Guus Sliepen
     Physics and Astronomy department
     Utrecht University



A. Taal et al.           Expires: June 2002                    [Page 22]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     Princetonplein 5
     3584 CC Utrecht
     The Netherlands

     Phone: +31 30 2537724
     Fax:   +31 30 2537555
     Email: G.Sliepen@phys.uu.nl


     Armijn Hemel
     Institute of Information and Computing Sciences
     Utrecht University
     Padualaan 14
     3584 CH Utrecht
     The Netherlands

     Email: aehemel@cs.uu.nl


     Cees de Laat
     Faculty of Science, Informatics Institute
     University of Amsterdam
     Kruislaan 403
     1098 SJ Amsterdam
     The Netherlands

     Phone: +31 20 5257590
     Fax:   +31 20 5257490
     Email: delaat@science.uva.nl






















A. Taal et al.           Expires: June 2002                    [Page 23]