view Side-By-Side changes

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




           A grammar for Policies in a Generic AAA Environment

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

                <draft-irtf-aaaarch-generic-policy-02.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 Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other docuí 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 September 2002                [Page 1]

Internet Draft     Grammar for Policies in Generic AAA     November 2001        March 2002


      Abstract

      In this document a formal model of a language to describe policies is presented to describe poli-
      cies in the context of a generic AAA environment. In such  We confine the
      discussion to so called Driving Policies.  A Driving Policy deter-
      mines the behavior of an environment, multiple domains or "kingdoms" are involved. Each
     domain has, in effect, Service Level Agreements (SLAs) AAA Server when it is confronted with other
     domains. Those SLAs and other rules that may apply to a domain are
     implemented as policies in
      specific message type of the AAA Servers. The policies protocol.  These Driving Policies
      should facilií
     tate facilitate AAA Servers from the various domains to work together
      in order to Satisfy Requests 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 Driving 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 other policies, since Service Level Agreements with other
      domains are implemented as a reference to a remote
     policy, a policy stored at a remote AAA Server. policies.
      Other important
     components features of a policy Driving Policy are calls the possibility
      to call generic functions the AAA Server is equipped with, and the
      possibility to delegate special tasks to so called Application
      Specific Modules.


Table of Contents

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









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

Internet Draft     Grammar for Policies in Generic AAA     November 2001        March 2002


1.  AAA environment

  +----+         +---+                                     +---+
        |AAA|<=============================================>|AAA|
        +---+<=============
  |User|<=======>|AAA|<===================================>|AAA|
  +----+         +---+<=========                 =========>+---+
                /\   /\         \\              //         /\   /\
                ||   ||         ||              ||         ||   ||
                ||   \/         ||              ||         ||   \/
                \/   +--+       ||              ||         \/   +--+
              +---+  |PR|       ||              ||      +---+   |PR|
              |ASM|  +--+       \/              \/      |ASM|   +--+
              +---+            +---+           +---+    +---+
                          |AAA|<=============>|AAA|
                               |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í 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 contains what kind of service the user wants.  This request
      is evaluated by the Rule Based Engine (RBE) of the AAA Server where
      a Driving Policy resides that needs to be evaluated with respect to
      the request.  The Driving Policy specifies the behavior of the AAA
      Server for a certain request.  For each message type of a future
      AAA protocol [OBJMSG] (section 4) there exists a corresponding Driving
      Policy that is evaluated.  These Driving Policies are stored in the
      Policy Repository (PR).

      Whether the request will be accepted or rejected depends on the
      evaluation of the Driving Policy.  In case the Driving Policy is
      part of a distributed policy, the AAA Server that receives the
      request has to communicate with other AAA Servers in order to fully
      evaluate the request. Complex and  For special tasks not possible or too
     cumbersome to express into the policy language are handled by AAA Server (RBE)
      resorts to generic components functions or by to so called Application Specific
      Modules (ASMs).

      Because Driving Policies can refer to local policies and to ASMs
      for complex tasks, taks, 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
      Administrator the possibility to adjust the behavior of an AAA
      Server without the necessity to recompile the AAA Server code.

A. Taal et al.           Expires: September 2002                [Page 3]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


2.  Use Case Diagram

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

                 Figure 2. Use Case diagram for a an AAA request

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

      The relationship between the Actor and this Use Case is a bi-direcí 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' 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 six Use Cases:

           - 'Satisfy Request' request'
           - 'Lookup Driving Policy'
           - 'Evaluate Driving Policy'
           - 'Authenticate User' user'
           - 'Authorize User' user'
           - 'Perform Accounting'

A. Taal et al.           Expires: September 2002                [Page 4]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


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


2.1.  The Use Case 'Satisfy Request' request'

      This Use Case will describe how an AAA Server deals with an AAA
     Request
      request issued by a device acting on the behalf of a real user,
      and what answers towards the user can be given [OBJMSG]. 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 the this policy and formulates a constructs the corres-
      ponding response.  It
     is  A more detailed view of importance that this Use Case would be
      the requester is well informed about set of Use Cases associated with the outí
     come different message types
      of his request, especially when his request is rejected. the AAA protocol.


2.2.  The Use Case 'Lookup Driving Policy'

      The AAA Server must retrieve the Driving Policy that needs to be
      evaluated before the request can be satisfied.  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 ad onto relationship 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  Any request will result in Generic AAA     November 2001 the lookup of the
      corresponding Driving Policy in the local Policy Repository (PR).


2.3.  The Use Case 'Evaluate Driving Policy'

      Policies can either be used in a stand-alone fashion or they can
      refer to other policies.  It is the task of the AAA Server to evalí 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í hap-
      pens it must be clear what logical relation this policy has with
      the stored Driving Policy, and whether this pushed policy contains
      conditions the user is not authorized to push.
      The request may contain objects (primitive data types ) to be sub-
      stituted for free variables occurring in the Driving Policy.  The
      RBE substitutes everything at the proper place into the policy.
      After the RBE has substituted all it knows, it decides whether the
      policy is false, true or undecided yet.  It is the responsií
     bility responsibility
      of the AAA Server to keep track of all the decision process. processes.


A. Taal et al.           Expires: September 2002                [Page 5]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


2.4.  The Use Case 'Authenticate User' user'

      The authentication of the user is the process of verifying the
      proof of his identity.  Authentication of the user is only perí per-
      formed if the Driving Policy under evaluation requires it.  When
      that is the case, the request must contain information about necesí 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,  Authentication and authorization is only performed
      if a 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.


3.  Policies


3.1.  Introduction

     As can be derived from the


2.6.  The Use Case diagram in fig. 2, 'Perform Accounting'

      Accounting is the behavior collection of an all the data about resource con-
      sumption.  Intermediate accounting or accounting indication informs
      the User about currently used resources.  The AAA Server is policy driven with respect must
      provide the information about which Resource Managers need to be
      consulted.  Resource Managers resorts to Meters that capture data
      about resource consumption in the network.



3.  Driving Policies


3.1.  Introduction

      As can be derived from the Use Case diagram in fig. 2, the behavior
      of an AAA Request. Server is policy driven with respect to a request.  In
      order to expand the Use Case 'Evaluate Driving Policy', it is
      important to have a model for policies.  In this section we will
      outline such a model.  It will have components we believe are necí nec-
      essary for any future model.
      There are several reasons to come with a formal model for a policy. Driving
      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.  For instance components like an ASM
      (Application Specific Module) provide the real functionality of an
      AAA Server, and therefore there will certainly be provisions for
      that in the  grammar.  The type of constructions defined in the

A. Taal et al.           Expires: September 2002                [Page 6]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


      grammar influence the ways in which the ASMs will be accessed, and
      therefore the way the whole AAA environment will react.
      Driving Policies might be distributed, i.e. a policy it may reference a policy
      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] [section ??] must be suited to
      accommodate the necessary information for remote policy evaluation.
      This shows an interdependence between the formal model and the
      object types of a future AAA protocol.

      Another important reason for a formal model of a policy is the need
     for
      to allow 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 request.  Obviously a standard protocol or
      language must exist for those policies so that the parí
     ties parties involved
      agree upon the contents of those policies. contents.

      Since the AAA concept (architecture and protocol) is a complicated
      one, there exists a large need for simulation.  As the behavior of
      an AAA Server is policy driven, the contents of the Policy Reposií 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 the elements, which will most
      likely be part of an official AAA policy grammar.  The grammar
      is kept as concise as possible, so that policies according to this
      grammar turn out to be a subset of existing policy languages.
      In section ?? a short outline is presented how these policies can
      be described by the policy language Ponder [PONDER].  We also
      present
     it this grammar to facilitate the discussion about AAA
      policies, and to document this language in order to explain the
      results of a possible simulaí
     tion simulation of a generic AAA system.  The
      notation of the grammar below is in EBNF (Extended Backus Naur
      Formalism), terminal symbols are placed between double quotes:

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

      Condition ::= BoolExpr

      BoolExpr ::= Bool



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 ")"

A. Taal et al.           Expires: September 2002                [Page 7]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


      UnaryBooleanOperator ::= "!"

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

      Procedure ::= PolicyRef | FunctionCall

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

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

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

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

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

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

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


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

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



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

      UnaryArithmeticOperator  ::= "-"

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


A. Taal et al.           Expires: September 2002                [Page 8]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


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

      Source ::= Identifier

      PolicyName   ::= Identifier
      FunctionName ::= Identifier

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

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

      A Policy (Driving Policy) can be viewed as an if-then-else construction. con-
      struction.  The Condií
     tion Condition (if-part) yields a Boolean value, which
      may be the result of evaluating a larger expression.  Recursion of
      Conditions is allowed and opens the possibility to make complex
      policies.  Both the then-part and the else-part consist of a list
      of Actions. 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í 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
      successfully executed.  A Policy is said to be false if and only
      if the Condition is false, and the Actions in the else-part are successí
     fully
      successfully executed.  In all other situations, the state of the
      Policy is undetermined due to the occurrence of an error.  As the
      grammar does not provide for exception handling, the only
      reasonable choice is to stop the evaluation of the Policy after
      error occurrence.

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

      Two other components of the model that can have a truth value are
      a PolicyRef and a Functioní
     Call. FunctionCall.  A PolicyRef is a reference to
      a policy that may reside in the same Policy Repository (local
      policy) or may reside at another AAA
     Server server (remote policy).  It
      should be clear that local or remore policies refered to in a
      Policy are not subjected to the grammar presented, they may be

A. Taal et al.           Expires: September 2002                [Page 9]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


      expressed in other policy languages.
      The component FunctionCall can be interí
     preted interpreted as a function call to
      an Application Specific Module (ASM), or more general a call of a
      generic library function the AAA Server might
     be server is equipped with.  An
      important concept is the result of a PolicyRef and a FunctionCall.
      With respect to the result their is no differí
     ence difference between a
      PolicyRef and a FunctionCall.  In general the result is an object
      tree, all members of the tree are accessible.  The root object of
      the object tree contains the truth value of the PolicyRef or
      FunctionCall.  As these components have a truth value, they can be
      part of a Condition or can be applied as an Action.  In the next
      sections we will explain the syntax of the grammar accompanied with
      remarks about the semantics of that grammar.


3.2.1.  Conditions

      A Condition is defined as an arbitrary Boolean formula, i.e. we
      don't make the restriction to a formula in DNF (Disjunctive Normal
      Form) or CNF (Conjunctive Normal Form) notation.  The introduction
      of brackets ensures avoids any ambiguity is avoided and, no ambiguity, without the need to define a
      precedence
     rules rule for operators the logical AND- ("&&") and OR-operator ("||").

      It is desirable to define how a Condition is evaluated, or in other constructions to resolve parsing coní
     flicts are needed. Apart from that,
      words the conventions from if-statement is said to be deterministic.  Here we
      follow the C laní
     guage are used. Conditions language, which also guarantees that `&&' and `||' are to be
      evaluated from left to right.  For an OR expression OR-expression it holds that the
      right operand is not evaluí
     ated evaluated if the left operand evaluates to
      true.  The same holds for the
     AND expression AND-expression if the left operand
      evaluates to false.  This also implies that different parts of a Policy
      Condition can not be evaluated in parallel.  From parallel
      evaluation follows that the requester should be satisfied with any
      result making the Condition true or false.  Consider an
      OR-expression composed of references to remote AAA Servers.
      Parallel evaluation means parallel requests to the remote AAA
      Servers.  There is no guarantee that the AAA Server with the first
      positive response will be the same any time the Driving Policy is
      evaluated.  In order to give an administrator more freedom to
      specify how a Condition should be evaluated, the grammar should be
      extended by concurrency operators.

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

     Policy 1:  if
                (
      equivalent:

      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:

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

A. Taal et al.           Expires: September 2002               [Page 10]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


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

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

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

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

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

          if



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


          (

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

     Herein

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

A. Taal et al.           Expires: September 2002               [Page 11]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


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

          if ( Request:

           if( exists Request.Bandwidth && Request.Bandwidth >= 10 )
          then (...)
           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 constants of different types in the same
      expression may result in an error state.  For example the
      multiplication of two variables, one representing a string and
      the other representing a floating point number is not defined. results in an
      abortion of the evaluation.


3.2.3.  Object trees

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

           Request:               --->
          - Identity
          - AuthenticationData

                                 <---                         Reply:
                                        -
             Identity                         Answer
             AuthenticationData

      Suppose the Identity object in the Request object request contains a string called
      UserID.  This member of the Request object may be repreí
     sented represented as a Var
      (variable) with the dot-structure: Request.Idení
     tity.UserID.  Request.Identity.UserID.
      A Var refers to an empty object tree if the head of the
      corresponding dot-structure is not the reserved word "Request" or
      "Reply", and it is neither the head of a previously mentioned
      dot-structure.  Such a Var may be interpreted as a leaf without a
      value.  With this definition in mind we propose the following
      semantics of assignments with variables is the following. 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.
1) The left and right hand side both refer refers to already defined an existent object
      tree, i.e. a non-empty object trees. tree. Then the assignment means that
      all children of E are copied and become the children of C.  All
      original children of C are lost.  If C is a leaf but E is a node,
      then C becomes a node.  In case both C and E are leaves, C remains
      a leaf but its value is changed to the value of E.

          2.


A. Taal et al.           Expires: September 2002                [Page 12]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


      2) The left hand left-hand side is an existing existent object tree whereas the
          right hand
      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.


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

          4.
      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 (PolicyRef) 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]. used.  Therefore, the name part
      (PolicyName) of the policy reference is limited to the name of one
      of these predefined message types.  This restriction does not hold
      for references to locally stored policies.  Such a reference has
      only a restriction with respect to the host name used. Like Procedures, a reference to a local policy might be
     accompanied with arguments and returns an object tree. This raises  If the question if a difference in syntax is necessary. A FunctionCall
     and a PolicyRef
      PolicyReference refers to a local policy, the PolicyName indicates
      which policy might should 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. retrieved from the Policy Repository.
      In general PolicyRefs are not interchangeable with the policies
      they refer to.


3.2.5.  Actions

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

     All
      They have to defined however, for reasons mentioned above.

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


A. Taal et al.           Expires: September 2002                [Page 13]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


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

          if
          (
            if (

           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 (
               if( packetready() )
               then( sendpacket() )
               else ( closefirewall() )
             )
             then (...) else (...) (...).


      The introduction of concurrency operators in the grammar opens the
      possibility to indicate in which order Actions should be executed.



3.3.  Errors

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

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

      Suppose that errors do not break or interfere with evaluation.  If
      in the above example (in the previous (previous section) openfirewall() fails,
      then continuing the evaluation of the Condition will cerí
     tainly certainly
      make sendpacket() fail as well.  In this example it is desirí
     able
      desirable 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 RBE 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 evaluation.  As exception handling
     in is not
      part of 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 most safe strategy is 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. evaluation.

      The administrator can make sure that the Policies are constructed
      in such a way that errors do not result in an undesirable the occurrence of error states are limited.
      This might be done by checking the input for Procedures if it meets

A. Taal et al.           Expires: June September 2002                [Page 15] 14]

Internet Draft     Grammar for Policies in Generic AAA     November 2001


     situation. This is shown in        March 2002


      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 precondition.  Take for instance 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 for band-
      width that contains an object ServiceData, say:

          ServiceData.Bandwidth = 100,
          ServiceData.Source = "3",
          ServiceData.Destination = "4",
          ServiceData.StartTime = T,
          ServiceData.StopTime = T + 3600 ServiceData.  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 precondition for bandwidth has been satisfied"
          )
          else (...)

     The reservation of the bandwidth is typically a task
      FunctionCall to the appropriate ASM, might be perí
     formed by an ASM.  As that the reservation of requested
      bandwidth between devices is at least 10 and at most 100.  Then 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 ( Driving Policy
      may look like:

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

     The grammar also allows Policies nested inside Conditions.  There
     are advantages



4.   Data Objects and disadvantages to this.  Take for example Message Types

      This section describes the
     following Policy which tries to send a packet through need for 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 specification 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 message
      types and 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 top level objects to use these Procedures be carried in a single
     Condition. future AAA
      protocol.  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 each message type there should be a corresponding
      Driving Policy.  Message types occur as a Request Reply couple.
      Such a list of the AND-expression. Only then it is clear which
     objects are available. It message types should certainly contain:

      a) Service Request/Reply
      b) Authorization Request/Reply
      c) Authentication Request/Reply
      d) Policy Request/Reply
      e) Policy Evaluation Request/Reply

      For instance, a Policy Request is better sent to rewrite this an AAA Server to obtain
      a remote policy.  It would contain a data object, Policy in Reference.
      The corresponding Reply would contain a Policy data object.

      Once these message types and data object are defined, UML Use Cases
      can be defined, describing by which an AAA server may be used by one
      of the
     following more deterministic way:

          if( X = Call1(...) )
          then
          (
            if( Y = Call2(...) )
            then(...)
            else(...)
          )
          else(...) AAA Actors.  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 result pre- and postconditions can be added about
      abstracted to guide the state construction of the evaluation.


3.5. corresponding Driving
      Policies.



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]. request.  A user issues an Authentication request
      containing the following objects: an Identity object and an
      AuthenticationData object [OBJMSG]. object.  The AAA Server server recognizes the request


A. Taal et al.           Expires: September 2002                [Page 15]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


      as an Authentication request and draws the corresponding Driving
      Policy from the PR.  Assume, the AAA Server server acts as a Key
      Distribution Center (KDC) for the Kerberos authentication protocol.
      The Kerberos protocol is comprised of three sub-protocols:

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

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

          c. (KRB_TGS_REQ )
      c) Client/Server Exchange; the client sends the server a Kerí
          beros Kerberos
      Application Request (KRB_AP_REQ)
      The following policy might be a Driving Policy for an incoming
      Authentication request:

      if
      (
         if( exists Request.AuthenticationData.Protocol.Name )
         then( )
              else
              ( )else( Reply.Answer.Type = MISSING_DATA; MISSING_DATA ,
                       Reply.Answer.Message = "Missing Protocol.Name" )

         &&

         if( Request.AuthenticationData.Protocol.Name == "Kerberos" )
         then( )
              else
              (
         else( Reply = Authentication@131.211.32.73(
               Identity = Request.Identity, Request.Identity ,
               AuthenticationData = Request.AuthenticationData )
              )

         &&

         if( exists Request.AuthenticationData.Protocol.MsgType )
         then( )
              else
              ( )else( Reply.Answer.Type = MISSING_DATA; 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
              ( else( Reply.Answer.Type = UNKNOWN_DATA; UNKNOWN_DATA ,
                       Reply.Answer.Message = "Unknown MsgType" )
      )
      then
      (
         // Action 1
         if
         (  exists Request.Identity.UserName
            &&
            exists Request.AuthenticationData.ServerName
            &&
            exists Request.AuthenticationData.PreAuthentication
         )




A. Taal et al.           Expires: September 2002                [Page 16]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


         then
         (
           // Action 1.1
           KRBReply =
             authenticate(
                 username          = Request.Identity.UserName,
                 servername        = Request.AuthenticationData.ServerName,
                 preauthentication = 
Request.AuthenticationData.PreAuthentication );
             )
             ;
             // Action 1.2
             Reply.Answer.AuthenticationData.SessionKey = KRBReply.SessionKey; KRBReply.SessionKey
             ;
             // Action 1.3
             Reply.Answer.AuthenticationData.TGT = KRBReply.TGT
         )
            else
            (
         else( Reply.Answer.Type = MISSING_DATA; 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,
      AuthenticationData object.  Furthermore, it is assumed that the
      last object contains a Protocol object. No additional assumptions are
     made about  About the contents of
      these objects. objects no additional assumptions are made.  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], reply object, by setting the variables Type and Message
      of the object Answer.  The first Action might be interpreted as
      assigning the variable Type to a predeí
     fined predefined integer called MISSING_DATA to the leaf node named Type of
     the Reply object.
      MISSING_DATA.  In case the first literal is found to be false, the
      Condition is false and the Actions in the else-part of the Driving
      Policy are executed.  The second literal has a reference to a
      remote policy (PolicyRef) as an Action.  This Action is executed
      if the authentication protocol requested differs from the Kerberos
      protocol.  It entails an AAA Request request issued to another AAA Server
      (131.211.32.73).  Information about what kind of AAA Request request has to
      be send, is provided by the name-part of the PolicyRef, which
      equals one of the message types defined.  Two arguments are passed
      to the policy reference, the Identity and the AuthenticationData
      object form the original request.  The assignment indicates that
      the response from the remote reference becomes the reply to the
      request.  Both remaining literals are similar to the first literal.
      One Action is given in the then-part of the Driving Policy.  This
      Action is a Policy which Condition checks for the existence of some

A. Taal et al.           Expires: September 2002                [Page 17]

Internet Draft     Grammar for Policies in Generic AAA        March 2002


      variables (objects), like UserName, ServerName, and PreAuthenticaí
     tion.
      PreAuthentication.  As this Action is a Policy, it has an
      ActionList of its own.  Of the three Actions in this list, the
      first might be interpreted as a call to an ASM.  The remaining
      Actions transport objects from the return tree to the Reply.


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 reply.



6. Ponder policy language

      The language according to push policies:

          1.  Policies might contradict each other, possibly resulting the presented grammar describes policies
      that can be implemented in unwanted behavior. for instance the Ponder policy language
      [PONDER].  Driving Policies should be implemented as obligation
      policies.  In Ponder an obligation policy specifies the case of pushed policies actions
      that must be performed by managers within the
          problem is more urgent than in system when certain
      events occur.  In the context of Driving Policies, an event is an
      AAA request issued by an user.

      In case of local policies coní
          tradicting each other (which a nested Driving Policy, i.e. a Policy occurs as a
      literal in a Condition, or as an Action in an ActionList, a
      composite policy in Ponder should be used.  The best choice is to
      use a fault of the local adminisí
          trators).  A pushed role, a composite policy doesn't in which all the policies have knowledge about the
          local policies.

          2.
      same subject.  In our case the subject is an automated component
      called RBE.  A pushed policy can contain `unwanted actions', resulting
          in a (possibly major) security risk.  This can result in role is also the
          server wasting processing time, bandwidth and other resources,
          leaving it choice if the Driving Policy is not
      nested, but has an non-empty ActionList in such the then-part.  Take for
      instance the following Driving Policy:

           if( Query = getPassWord( userid = Request.UserID )
               &&
               Request.PassW = Query.PassW
             )
           then( action11( ) ; action12( ) )
           else( action21( ) ; action22( ) )

      In Ponder this may look like:

      type role authentication( Request req, Reply rep, Domain T )
      {
       inst oblig authentication1 {
                  on authentication_request( );
                  target T->select( t0, t11, t12 | true );
                  do t12.action11( )->t2.action12( );
                  when req.PassW = t0.getPassW( req.UserID );
            }

            oblig authentication2 {
                  on authentication_request( );
                  target T->select( t0, t21, t22 | true );
                  do t21.action21( )->t22.action22( );
                  when req.PassW <> t0.getPassW( req.UserID );
            }
      }
      inst role a state that it can't process other
          requests. = authentication( /Request, /Reply, . . . ) @ /RBE

A. Taal et al.           Expires: June September 2002                [Page 21] 18]

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,        March 2002


      In general a policy nested Driving Policy can always be pushed by storing it written as a set
      of simple Policies, i.e. a non-nested Policy with an empty
      ActionList in the then-part.
      For example, a Request
     object. Policy as a literal:

      if( A special message type should be used && if( B ) then( b11 ) else( b21 ) ) then( a11 ) else( a22 )

      is equivalent to indicate the following set of Policies:

      1) if( A && B ) then( b11 ; a11 )

      2) if( A && !B ) then( b21 ; a21 )
      3) if( !A ) then( a21 )

      Here it is assumed that the evaluation of a
     pushed policy has Condition is stopped as
      soon its truth-value is determined.  Therefore, if A turns out to
      be processed.  The Driving Policy for this
     request can decide whether the pushed policy false, B is accepted or not.
     If it is, the object containing not evaluated.
      Each of the pushed policy could simple Policies can be passed
     to implemented as a special FunctionCall which in turn extracts the policy and
     feeds it to the separate
      obligation policy evaluation mechanism of the AAA Server.
     This way, no special provisions are needed in the policy language
     itself to allow pushed policies. a role, as outlined above.



































A. Taal et al.           Expires: September 2002                [Page 19]

Internet Draft     Grammar for Policies in Generic AAA        March 2002



References

      [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Vollí 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

      [PONDER] http://www-dse.doc.ic.ac.uk/research/policies/ponder.html



Authors' Addresses

      Arie Taal
      Faculty of Science, Informatics Institute 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 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 September 2002                [Page 23] 20]


----