view Side-By-Side changes

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




          A grammar for Policies in a Generic AAA Environment

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

               <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- 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: December 2001 June 2002                     [Page 1]

Internet Draft     Grammar for Policies in Generic AAA         June     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 policies in AAA Servers. The goal is to setup an
      environment where the policies should facilií
     tate AAA Servers from the various domains can to work together in order
     to satisfy requests Satisfy Requests from users for services that cross those
     domains.

      In order to allow distributed policies in For complex services, not all knowledge can be packed into
     a generic AAA environé
      ment, single policy.  Therefore, a policy must be able to reference
     another policy. This means
      that parts of a distributed policy may might be stored and evaluated at a
      remote AAA server. A reference to a local policy, i.e. a policy
     stored in at the same AAA server Server, as the referencing well as a reference to a remote
     policy, should be
      interchangeable with the a policy referenced. To facilitate this feaé
      ture the stored at a remote AAA Server. Other important
     components of a policy language must allow recursion. 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
      Table of Contents . . . . . . . . . . . . . . . . . . . . . . .   2
     1. AAA environment  . . . . . . . . . . . . . . . . . . . . . .   3
     2. Use Case Diagram . . . . . . . . . . . . . . . . . . . . . .   5   4
     2.1. The Use Case 'Satisfy request' Request' . . . . . . . . . . . . . .   6   5
     2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . .   6   5
     2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . .   6
     2.4. The Use Case 'Authenticate user' User' . . . . . . . . . . . . .   7   6
     2.5. The Use Case 'Authorize User'  . . . . . . . . . . . . . .   7   6
     3. Policies . . . . . . . . . . . . . . . . . . . . . . . . . .   7   6
     3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . .   7   6
     3.2. Formal model . . . . . . . . . . . . . . . . . . . . . . .   8   7
     3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . .  11  10
     3.2.2. Constants and variables  . . . . . . . . . . . . . . . .  14  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  . . . . . . . . . . . . . . . . .  17  16
     3.5. Example Policy . . . . . . . . . . . . . . . . . . . . . .  19  18
     3.6. Pushing Policies . . . . . . . . . . . . . . . . . . . . .  20  21
     References  . . . . . . . . . . . . . . . . . . . . . . . . . .  21  22
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . .  21  22




A. Taal et al.           Expires: December 2001 June 2002                     [Page 2]

Internet Draft     Grammar for Policies in Generic AAA         June     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é environí
     ment [RFC2903], and what kind of components it consists of.  Only
     those components are presented that are necessary to illustrate the
     discussion in this draft.  An AAA Server may receive a request from
     an entity operating on a user's behalf.  The content contents of the
     request
      contains 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.

      A policy is a set  The Driving Policy specifies the behavior of rules to administer, manage, and control
      access to network resources.  An the AAA
     Server manages for a certain request.  For each message type of a future
     AAA protocol [OBJMSG] there exists a corresponding Driving Policy Reposé
      itory (PR) where Policies reside.
     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, distributed policy, the AAA Server that receives the
     request has to communicate with other AAA Servers in order to fully
     evaluate the request.  Some parts of a policy might Complex and special tasks not be able possible or too
     cumbersome to
      be express into the policy language are handled by a
     generic component components or the policy language itself.
      In that case the AAA Server resorts to an by Application Specific Modé
      ule (ASM) Modules (ASMs).
     Because Driving Policies can refer to local policies and to ASMs
     for that part. 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: December 2001 June 2002                     [Page 3]

Internet Draft     Grammar for Policies in Generic AAA         June     November 2001



             +-------------------------------------all-sessions-+
             |+---------------------------one-session-+         |
             || +---+     +-------------+


     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

        +-+  +---+ |         |
        1    || |PD |-    |RBE / Control|  |R| -|PD | |         |    1
      =========>|aaa|-----|Module / Req.|--|B|--|aaa|===================>
             || |   |-    |Manager      |  | | -|   | |         |
             || +---+     +-------------+
        +-+  +---+ |         |
             ||   |         |  |  |  |            |   |         |
             ||   |        /   |  |   \
         |     request   +-----------------+      <<include>>
       ----- <=========> | Satisfy Request |============
         |               +-----------------+           || +---+
        /    |  | \        +---+ |         |                   || |SEC|    |     |   \    \       |SEC| |         |                       \/
       User                   || <<include>>  +-----------------------+
                              \/              | Lookup Driving Policy |  +---+   |   +--+  \      |   | |  +----+ |
             || +---+  |API|    \  |PD|   \     +---+ |  |Sess|
              +-------------------------+     +-----------------------+
              | Evaluate Driving Policy *<====
              +-------------------------+     \\ <<extend>>
                           /\                  \\  policy requires
                <<extend>> ||        |asm|     \ +--+    \          |  |Man.| |                   \\ authorization
           policy requires ||        +---+     +--+  \    -------------|    | |                   ||         /|\      |PD|   \             |  |    | |
            authentication ||        / | \     +--+    -----        |  +----+ |                   ||       /  |2 \        \        \       |
                 +-------------------+    +----------------+
                 |
             |+------/---|---\--------\--------\------+ Authenticate User |    |      / Authorize User |    \        \        \               |
             +-----/-----|-----\--------\--------\--------------+
                  |      |      |        |        |
                +---+  +---+  +---+   +-----+  +-----+
                |ASM|  |ASM|  |ASM|   |DB   |  |DB   |
                |   |  |   |  |   |   |event|  |pol. |----(Driving Policy)
                +---+  +---+  +---+   |log  |  |repos|
                 /|\    /|\5   /|\    +-----+  +-----+
                 ...    ...    ...
                 +-------------------+    +----------------+

                  Figure 2. The abstract view of Use Case diagram for a generic AAA Server [AAAGEN]

      A more detailed view of the AAA Server itself reveals request


     We will consider the Driving
      Policy.  The role of a Driving Policy specifies in response to a so
     called request.  To illustrate the behavior scope of this policy in the
     generic AAA
      Server for environment, we present a certain request.  For example, the Driving Policy in UML Use Case diagram for a
      shop
     future system of AAA Server would define Servers, fig. 2.  As this is not the shop functions.

      If ASMs are involved, right
     document to fully describe the Driving Policies Use Cases in the PR and the ASMs
      have fig. 2, only a dependency relation, because the policies can refer to an
      ASM to solve concise
     description is presented.  We define a part of single Actor, called User,
     as an entity that speaks the policy. AAA protocol.  This means that generalized user
     wants a request to be satisfied, the content of Use Case 'Satisfy Request'.

     The relationship between the PR Actor and this Use Case is a bi-direcí
     tional association.  It depicts the ASMs determine the behavior of the AAA Server.

      A change of the contents participation of the PR and the ASMs will result Actor in a
      different AAA Server.  This feature should be dynamically supported
      to give an administrator
     the possibility to adjust Use Case.  This association is bi-directional because the behavior of User
     expects an AAA Server without the necessity answer to recompile his request.

     At the highest level we have:

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



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


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 3. Use Case diagram for a request


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

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

      At the highest level we have:

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


          - Actors:        User
          - Precondition:  none

     In total we distinguish five Use Cases:

          - 'Satisfy request'



A. Taal et al.           Expires: December 2001                 [Page 5]

Internet Draft     Grammar for Policies in Generic AAA         June 2001 Request'
          - 'Lookup Driving Policy'
          - 'Evaluate Driving Policy'
          - 'Authenticate user' User'
          - 'Authorize user' User'

     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' are only peré perí
     formed 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.  Every given [OBJMSG].  Every request
     is foré
      warded 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 outcome 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é 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



A. Taal et al.           Expires: December 2001                 [Page 6]

Internet Draft     Grammar for Policies in Generic AAA         June 2001
     conditions the user is not authorized to push.  The request may
      contain Attribute Value Pairs (AVP), which values have to be subé
      stituted for free variables occurring in the policy.  Some free
      variables in the policy may only be solved by a specific applicaé
      tion.  For those free variables the AAA Server resorts to the
      Application Specific Module (ASM) for that application.  The AAA
      Server substitutes these values at the proper place into the polé
      icy.  After the AAA Server has substituted all it knows, it decides
      whether the policy is false, true or undecided yet.  It is the
      responsibility responsií
     bility of the AAA Server to keep track of the decision proé
      cess and combine the answers retrieved into an answer for the user. process.


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, authorization is only performed
     if a Driving Policy requires it.  It is not strictly necessary to
     perform authentication before authorization.  There are cases where
     the decision whether the request is authorized or not does not in
     any way depend on information about the user.


3.  Policies


3.1.  Introduction

     As can be derived from the Use Case diagram in fig. 3, 2, the behavior
     of an AAA Server is policy driven with respect to a request. 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é necí
     essary for any future model.




A. Taal et al.           Expires: December 2001                 [Page 7]

Internet Draft     Grammar for Policies in Generic AAA         June 2001  There are several reasons to come
     with a formal model for a policy.  In this document a grammar is



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 grammar influé
      ence 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 necesé
      sary
     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
      to allow
     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 a request.  Obviously an AAA Request.  Obvií
     ously a standard protocol or language must exist for those policies so that the parties parí
     ties involved agree upon the contents. 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 content 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 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é simulaí
     tion of a generic AAA system.  The notation of the grammar below is
     in EBNF (Extended Backus Naur Formalism): 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 8] 7]

Internet Draft     Grammar for Policies in Generic AAA         June     November 2001


      Condition ::= Literal


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

          UnaryBooleanOperator ::= "NOT"
                             | "!"

          BinaryBooleanOperator ::= "AND"
                              | "OR"
                              | "&&" | "||"
      Literal

          Procedure ::= Bool
                | BoolVar PolicyRef | ComputedBoolean
                | Policy
                | {Source "="}? BooleanProcedure

      BooleanProcedure ::= FunctionCall

          PolicyRef
                        | ASMCall

      ASMCall ::= ASMName PolicyName "@" Hostname "(" ARGList ")"

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

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

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

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

          Action ::= "AVP" Name Var "=" Param Bool
                   | {Source "="}? BooleanProcedure

      Param ::= Condition Var "=" ComputedBoolean
                   | IntExpr Var "=" NonBooleanExpr
                   | FloatExpr {Var "="}? Procedure
                   | StringExpr Policy

          ComputedBoolean ::= IntExpr ComparisonOperator IntExpr
                        | FloatExpr ComparisonOperator FloatExpr
                        | StringExpr NonBooleanExpr ComparisonOperator StringExpr NonBooleanExpr
                            | "exists" Source "." Name Var

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

      IntExpr

          NonBooleanExpr ::= "(" IntExpr BinaryArithmeticOperator IntExpr ")" Int
                           | Float
                           | String
                           | Var
                           | UnaryArithmeticOperator IntExpr NonBooleanExpr
                           | IntVar "(" NonBooleanExpr



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


                | Int

      FloatExpr ::= "(" FloatExpr


                                 BinaryArithmeticOperator FloatExpr ")"
                  | UnaryArithmeticOperator FloatExpr
                  | FloatVar
                  | Float

      StringExpr ::= "(" StringExpr "+" StringExpr NonBooleanExpr ")"
                   | StringVar
                   | String

          UnaryArithmeticOperator ::= "-"

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

      BoolVar ::= "BOOL" Source "." Name
      IntVar ::= "INT" Source "." Name
      FloatVar ::= "FLOAT" Source "." Name
      StringVar

          Var ::= "STRING" Source "." Name
      Name ::= Identifier {"." Source}*

          Source ::= Identifier
      PolicyRef ::=

          PolicyName "@" Hostname "(" AVPList ")"
      AVPList ::= {AVP {"," AVP}*}?
      AVP   ::= Source "=" Param
      PolicyName Identifier
          FunctionName ::= Identifier

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

          Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*"
          String ::= "[^"\n]*" "\"[^"\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é 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 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é exeí
     cuted when the Condition is false.  To a Policy we also attach a
     Boolean value.  We define a Policy to be true if and only if the
     Condition is true, and the Actions of the then-part are



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


      successfully 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 sucé
      cessfully successí
     fully executed.  In all other situations, the state of the Polé
      icy Policy
     is undetermined due to the occurrence of an error. As the gramé
      mar grammar
     does not provide for exception handling, the only reasonable choice
     is to stop the evaluation of the Policy after error occuré
      rence.  An important concept of occurrence.

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



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 list that contains at least one element.
      The first element Policy
     is part of this list a Condition, or is used as an Action, its truth value
     determines the result truth value of the evaluation of Policy one level up in the Condition (i.e., true or false).  All additional elements nestí
     ing.

     Two other components of the list model are attribute-value pairs (AVPs).  Those AVPs can be added
      to the list by a special Action indicated by the key word "AVP"
      (e.g. AVP Permission=true).  This concept of PolicyRef and a list is also
      attached to the components PolicyRef and ASMCall.  A PolicyRef Functioní
     Call. A PolicyRef is a reference to a Policy policy that may reside in the
     same Policy Repository (local policy) or may reside at another AAA server
     Server (remote policy).  The component ASMCall FunctionCall can be interpreted interí
     preted as a procedure function call to an Application Specific Module (ASM),
     or more general a call of a library function the AAA server is 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 difference differí
     ence between a Policy, a PolicyRef and a FunctionCall. In general the result
     is an ASMCall. 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 three components have a Boolean value truth value, they can
     be part of a Condition.  Furthermore, these three components Condition or can also be applied as Actions.

      A consequence of policy references is the need of communication
      between AAA Servers during policy evaluation.  A future AAA protoé
      col should provide for request/response objects in order to support
      referencing remote policies [OBJMSG].

      Policies can be nested in both Conditions as well as Actions.  A
      Policy in the then-part and else-part of a Policy gives the possié
      bility to express a more deterministic policy, while allowing a
      Policy within a Condition introduces the notion of `attaching
      Actions to subexpressions of a Condition'. 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 avoids ensures any ambiguity, without the need to define a ambiguity is avoided and, no precedence rule
     rules for the logical AND and OR operator.

      It is desirable to define how a Condition is evaluated, operators or in other



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


      words the if-statement is said constructions to be deterministic. 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 evaluated evaluí
     ated if the left operand evalué
      ates 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 Policy can not be evaluated in
     parallel.

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

     Policy 1:  if(  if
                (
                  if ( C1 ) then ( A11 ) else ( A12 )
                   AND
                  &&
                  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(
                then
                (
                  A11;
                  if( C2 ) then( A11, A21, A21; A00 ) else( A11, A22, A22; A01 )
                )
                else ( A12, A12; A01 )

     A Condition, or Boolean formula, expression, is composed of five different
     types of operands (Literals): (literals): Bool, BoolVar, Var, ComputedBoolean, Polé
      icy Proceí
     dure, and BooleanProcedure. Policy. An operand of type Bool Bool, Var, ComputedBoolean, or
     Policy is just the Boolean value true or false. The type BoolVar refers to an AVP,
      which has a Boolean value ( see below ).

     A ComputedBoolean is a comparison between a left and right hand
     expression.  Both expressions must be of the same type.  Three
      types of expression are defined: an expression of integers (Inté
      Expr), an expression of floating point numbers (FloatExpr), and an
      expression of strings (StringExpr). An important aspect of an expression is that it can
     contain varié
      ables (IntVar, FloatVar, StringVar).  In propositional calculus, a
      ComputedBoolean is a just a predicate with free variables. variables (Var).

     A varié
      able has three components: a Type, a Source, and a Name.  The Type
      component specifies whether the variable is an integer (INT), a
      floating point number (FLOAT) or (Var) refers to a character string (STRING).  Both
      the Name and Source component node (sub-tree) of an object tree. The
     corresponding dotted notation provides the RBE (Rule Based Engine)
     with the information where the value of that variable sub-tree referenced can be
     retrieved.

      All variables are attribute-value pairs (AVPs), whether specified
      in the AAA-request, or as an AVP returned from a BooleanProcedure.




A. Taal et al.           Expires: December 2001                [Page 12]

Internet Draft     Grammar for Policies in Generic AAA         June 2001 The two types object tree of BooleanProcedure are equivalent in the sense that
      they all result in a list, which first value (or head) contains
      true or false.  All other members request always starts with the
     reserved word "Request", whereas the object tree of the list are attribute-value
      pairs.  These two BooleanProcedures are a PolicyRef and an ASMCall. 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, ASMCall, FunctionCall, may be interpreted as a function call to an Applicaé
      tion
     Application Specific Module (ASM), Module, or as a call to a library function.  In
      order to access the AVPs in a list returned form
     Both Procedures, a BooleanProceé
      dure, one has to assign PolicyRef and a Source-name to it. Only one Source-name FunctionCall, are equivalent in
     the sense that the result is reserved, "Request", which refers to AVPs an object tree. If an assignment is
     made all parts of this result tree are accessible in the Request. 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 this mechanism.
      Herein the password supplied in the request has to be compared with
      the password some of the user stored in the authentication database:
     concepts dealt with above:

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



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 a parameter. an argument. This parameé
      ter argument
     refers to an AVP a variable called "UserID" in the Request and is of the
      type STRING. As a result, getPassword() returns a list from which
      it can be inferred whether the call was successful or not (first
      member of the list). object.  By
     making the assignment "Query=getPassé
      word(...)" , "Query = getPassword(...)", the AVPs password in
     the return list tree can be referred to. This is done in the right hand
     side of the AND.

      A BooleanProcedure can be applied in a Condition without an assigné
      ment.  In that case the AVPs in the return list are not accessible.
      Only the Boolean (true or false) result of the ASM procedure or
      remotely evaluated Policy is used. Condition.

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

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



A. Taal et al.           Expires: December 2001                [Page 13]

Internet Draft     Grammar for Policies in Generic AAA         June 2001
          else (...)


3.2.2.  Constants and variables

     The grammar allows four types the use of constants and variables: BOOL,
      INT, FLOAT and STRING.  The machine types corresponding to these
      types are: bool, 32 bit signed int, 32 bit IEEE floating point and
      8-bit ISO-8859-1 string.  This allows variables, but like in
     other scripting languages (e.g. JavaScript) the grammar does not
     provide for type checking by checking. Therefore, the RBE,
      e.g. an AVP use of type FLOAT specified variables and coní
     stants of different types in the same expression may result in a Policy will generate an
     error if state. For example the AVP in multiplication of two variables, one
     representing a string and the list referred other representing a floating point
     number is of type STRING. not defined.


3.2.3.  Actions

      In order to reduce unexpected effects  Object trees

     As mentioned above, variables (Vars) refer to a minimum and make sure
      that different AAA Servers always exhibit the same behavior, we
      propose member of an object
     tree. We use the following semantics with respect to Actions.  The
      requirements mentioned below are arbitrary in the sense that
      another policy language might impose different requirements.  They
      have to defined however, for reasons mentioned above. definitions. A node is a leaf if it has
     no children. All Actions in other nodes are internal nodes. If a Var refers to
     a leaf of an ActionList must always be executed immediately
      after evaluating the corresponding Condition.  Immediately here object tree, it refers to a primitive type, like a
     bool, int, float or string value. A reference to an internal node
     means that Actions are executed in the order in which they appear
      in the ActionList, and Var refers to an Action is only executed when the previous
      Action has finished successfully.  During execution object, i.e. a sub-tree of the Actions
      in the ActionList, policy evaluation is postponed.
     object tree starting at that specific internal node.

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

           if(
               if firewallready()
               then ( openfirewall() )
               else (...)
             AND
               if packetready()
               then( sendpacket() )
               else ( closefirewall() )
           )
           then (...) else (...)

      A very special Action is the one which adds an AVP to instance the return Authentication Request/Reply [OBJMSG]:



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


      list.  Wherever this Action occurs


          AAA Client                    AAA Server

          Request:               --->
          - Identity
          - AuthenticationData

                                 <---   Reply:
                                        - Answer

     Suppose the Identity object in the Request object contains a Policy, string
     called UserID.  This member of the AVP is added 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 return list head of
     the outer most Policy. In corresponding dot-structure is not the example below reserved word "Request"
     or "Reply", and it is neither the
      Actions 'AVP Error="Firewall not ready" ' and 'AVP Error="Packet
      not ready"' result in the addition 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 corresponding AVP to the
      result list semantics of assignments
     with variables is the outer policy.

           if(
               if firewallready()
               then( openfirewall() )
               else( AVP Error="Firewall not ready" )
             AND
               if packetready()
               then( sendpacket() )
               else (
                 closefirewall(),
                 AVP Error="Packet not ready"
               )
           )
           then (...) else (...)

      If on the contrary we only add AVPs to following. Consider the return list assignment of the inner
      most Policy, assignments should
     form Var = Var with corresponding dot-structure A.B.C = D.E. Four
     different cases can be made in order to make these AVPs
      available distinguished.

          1. The left and right hand side both refer to already defined
          object trees. Then the rest assignment means that all children of E
          are copied and become the Policy, otherwise the return AVPs children of
      the inner most Policy would be C. All original children
          of C are lost.


3.3.  Errors

      There If C is a leaf but E is a node, then C becomes
          a node. In case both C and E are several circumstances under which errors can occur during
      the evaluation of policies or leaves, C remains a leaf but
          its value is changed to the execution value of actions. E.

          2. The Policy might refer to AVPs that are missing.  An ASM function,
      for example getPassword(), might generate left hand side is an error, because for
      example existing object tree whereas the password
          right hand side is not found in an empty (not yet declared) object tree.
          This means that the database, or because sub-tree of the
      database tree at the left-hand side
          starting at node C is off-line.  Actions can also generate errors, for
      instance openfirewall() may fail.  Since we allow arithmetic
      expressions, another type of error might be caused by deleted. Node C becomes a division by
      zero.  AVPs might contain values 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 different type than given in 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 Policy.

      Suppose moment an error
     occurs.

     The administrator can make sure that the Policies are constructed
     in such a way that errors do not break or interfere with evaluation.  If 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 above example (in 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 previous section) openfirewall()
      fails, then continuing necesí
     sary bandwidth.  This request is sent to the evaluation of AAA Server at location
     "2" (a bandwidth broker).  There the Condition will ceré
      tainly make sendpacket() fail as well.  In this example it request is
      desirable that recognized as a
     request for bandwidth reservation.  The User, or rather the evaluation stops after applií
     cation acting on behalf of the first error.

      However in real user, has the following example it might be desirable a priori knowlí
     edge which parameters are needed by the AAA Server to fulfill his
     request.  Those parameters are added to continue the evaluation, whether errors occur or not: 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: December 2001 June 2002                    [Page 15] 16]

Internet Draft     Grammar for Policies in Generic AAA         June     November 2001


          then
          ( ( A or B ) or ( C or D )
            Reply.Answer.Message = "Request for bandwidth has been satisfied"
          )

      Let this
          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 scenario where A, B and C generate complicated process, different errors but are
      ignored, and D is evaluated true without any errors.  This Condié
      tion might still make sense.  Take for example can occur.  However, the
     grammar allows a broker nested if-then-else structure by which has
      to distribute tasks to a pool of servers, some the occurí
     rence of which might not errors can be online. 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 consideration whether to stop or continue after an error grammar also
      holds allows Policies nested inside Conditions.  There
     are advantages and disadvantages to this.  Take for ActionLists.  Suppose an administrator writes down example the
     following policy: Policy which tries to send a packet through a firewall if
     both firewall and packet are ready:

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

      If it happens that the first Action, openfirewall(), is successful
      but the second Action, sendpacket(), fails, it is desirable to coné
      tinue with the third Action, closefirewall().  If on the contrary
      the first Action fails, it is desirable to stop.

      So, when an error which is not caught by whatever construction in

     Note the Policy occurs, fact that the AAA Server either FunctionCall closefirewall() has to ignore the error
      and continue or abort evaluation.  Both choices have advantages appear
     twice in
      some situations, this Policy, and disadvantages in others.  The AAA Server cané
      not decide for itself what is best.  A possible solution might be
      to introduce exception handling in the grammar, so fact that the policy
      administrator can tell second sub-expression
     (where the AAA Server how to react in case an error
      occurs.

      Again, an `arbitrary' choice packet is sent if it is ready) now has to be made in order to make all
      AAA Servers react in the same way to errors.  Since errors occuré
      ring early in the policy evaluation might trigger even more errors
      later on, possibly resulting in a disastrous cascade, we will
      require that AAA Servers abort evaluation responsibilí
     ity of a Policy the moment an
      error occurs.

      The policy administrator can make sure that closing the policies are coné
      structed in such a way that errors do not result in an undesirable
      situation.  This firewall if there is shown in a problem.  Now take this
     functionally equivalent Policy, where the next section. nesting is done inside



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


3.4.  Construction guidelines

      An example:

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

      Suppose a User at location 1 wants bandwidth to start a video
      stream at time t=T from location 3


     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 location 4.  The User issues
      a request, say at t=0 refer to reserve the necessary bandwidth.  This
      request an object tree returned by different Proí
     cedures it is sent 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 AAA Server at location "2".  There else-part to
     determine whether the
      request is recognized as a request for bandwidth reservation.  The
      User, Condition became false due to the application acting on behalf left or
     right operand of the real user, has the a
      priori knowledge AND-expression. Only then it is clear which parameters are needed by the AAA Server to
      fulfill his request.  Those parameters
     objects are added available. It is better to the request as
      attribute-value pairs, say:

           - Bandwidth = 100
           - Source = "3"
           - Destination = "4"
           - StartTime = T0
           - StopTime = T1

      The Driving rewrite this Policy applied by in the AAA Server may look like:

           if reserveBandwidth(STRING Request.Source,
                               STRING Request.Destination,
                               INT Request.Bandwidth,
                               FLOAT Request.StartTime,
                               FLOAT Request.StopTime)
     following more deterministic way:

          if( X = Call1(...) )
          then
          (
             AVP status="Request
            if( Y = Call2(...) )
            then(...)
            else(...)
          )
          else(...)

     As holds for bandwidth any programming language, the writer has been satisfied"
           )
           else (...)

      The reservation 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 bandwidth is typically evaluation.


3.5.  Example Policy


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



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


      performed by an ASM.  As     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 reservation of bandwidth between
      devices Kerberos authentication protocol.
     The Kerberos protocol is comprised of three sub-protocols:

          a. Authentication Service Exchange; the client sends a complicated process, different errors can occur.  Howé
      ever, Kerí
          beros Authentication Service Request (KRB_AS_REQ)

          b. Ticket-Granting Service Exchange; the grammar allows client sends a nested if-then-else structure by which Kerí
          beros Ticket-Granting Service Request (KRB_TGS_REQ)

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

     The following policy might be reduced, a Driving Policy for instance by checking
      the preconditions: an incoming
     Authentication request:

          if
          (
              if( exists Request.Bandwith && INT Request.Bandwidth >= 10 Request.AuthenticationData.Protocol.Name )
           then (
             if ( INT Request.Bandwidth <= 500
              then( )
             then (...)
              else
              ( AVP error="Requested bandwidth too large" )
                Reply.Answer.Type = MISSING_DATA;
                Reply.Answer.Message = "Missing Protocol.Name"
              )
           else ( AVP error="Requested bandwidth too small"
            &&
              if( Request.AuthenticationData.Protocol.Name == "Kerberos" )

      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()
              then( )
              else
              ( AVP error="Firewall not ready" )
              AND
                if packetready()
                then ( sendpacket()
                Reply = Authentication@131.211.32.73(
                          Identity = Request.Identity,
                          AuthenticationData = Request.AuthenticationData )
                else (
                  closefirewall(),
                  AVP error="Packet not ready"
              )
            &&
              if( exists Request.AuthenticationData.Protocol.MsgType )
           then ( closefirewall()
              then( )
              else (...)

      Note the fact that the ASM function closefirewall() has to appear
      twice in this policy, and the fact that the second subexpression
      (where the packet is sent if it is ready), now has the responsibilé
      ity of closing the firewall if there is a problem.  This means that
      the second subexpression cannot be easily replaced by a RemotePolé
      icy (it can, but it loses the benefit of modularity).

      Now take this functionally equivalent Policy, but now the nesting
      is done inside Actions:

           if firewallready()
           then (
             openfirewall(),
             if packetready()
             then
              ( sendpacket()
                Reply.Answer.Type = MISSING_DATA;
                Reply.Answer.Message = "Missing Protocol.MsgType"
              )
            &&
              if( Request.AuthenticationData.Protocol.MsgType == KRB_AS_REQ )



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


             else ( AVP error="Packet not ready" ),
             closefirewall()


              then( )
              else
              ( AVP error="Firewall not ready" )

      If one wants to refer to AVPs returned by different BooleanProceé
      dures it is not recommended to use these BooleanProcedures in a
      single Condition.  For example:

           if ( x
                Reply.Answer.Type = call1(...) AND y UNKNOWN_DATA;
                Reply.Answer.Message = call2(...) "Unknown MsgType"
              )
          )
          then (...)
           else (...)

      In this example several Actions are required in the else-part to
      determine whether the Condition became false due to the left or
      right operand of the AND.  Only then it is clear which AVPs are
      available.  It is better to rewrite this Policy in the following
      more deterministic way:
          (
            // Action 1
            if
            ( x = call1(...)
              exists Request.Identity.UserName
              &&
              exists Request.AuthenticationData.ServerName
              &&
              exists Request.AuthenticationData.PreAuthentication
            )
            then
            (
             if ( y
              // 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 = call2(...) KRBReply.TGT
            )
             then (...)
            else (...)
            (
              Reply.Answer.Type = MISSING_DATA;
              Reply.Answer.Message = "AuthenticationData incomplete"
            );
            ...
          )
          else (...)

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


3.5.  Example Policy
          ( ... )

     In this section we present a Policy for network access.  A user
      issues a request for network access with the following AVPs:

           UserID="myName"
           PassW="@#!a"

      Furthermore the request contains information from which the AAA
      server can infer which Policy is needed.  Suppose this above Driving Policy is
      the one given below.  The a Condition of this Policy four ANDed Policies is
     evaluated.  Here we assume the following precondition: a reference
      to a remote Policy, "getProfile", at an proper AAA server called
      "user.server.org".  Two AVPs from the
     Authentication request are passed as argué
      ments, "UserID" containing an Identity object and "PassW".  By assigning a Source "UserProfile"
      to this reference, an AVP "GroupID" from 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 return list is



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


      available inside this Policy.


     Boolean expression (Condition), a Policy, checks if the Protocol
     object contains a variable called Name. If this call 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 remote policy predeí
     fined integer called MISSING_DATA to the leaf node named Type of
     the Reply object. In case the first literal is
      successful, found to be false,
     the Condition is false and the two Actions in the else-part of the ActionList
     Driving Policy are executed.  First
      an The second literal has a reference to
     a locally stored Policy.  This Action takes remote policy (PolicyRef) as
      argument an AVP called "GroupID" Action. This Action is executed
     if the authentication protocol requested differs from the return list "UserProé
      file".  As a result Kerberos
     protocol. It entails an AVP "Permission" AAA Request issued to another AAA Server
     (131.211.32.73). Information about what kind of AAA Request has to
     be send, is available in provided by the return
      list "AppRules". 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 second Action, an inline Policy, checks if
      this AVP has a Boolean value true. If so, an IP-address 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 assigned a Policy which Condition checks for the existence of some
     variables (objects), like UserName, ServerName, and PreAuthenticaí
     tion. As this Action is passed as a Policy, it has an argument ActionList of its own.
     Of the three Actions in an this list, the first might be interpreted
     as a call to setup a Session.

           if UserProfile=getProfile@user.server.org(
                          userid=STRING Request.UserID,
                       passw=STRING Request.PassW)
           then (
             AppRules=getAppRules@localhost(
                      groupame=STRING UserProfile.GroupID),
             if BOOL AppRules.Permission
             then (
               if IP=assignIPAddress()
               then (
                 if Session=sessionSetup(
                            STRING Request.UserID,
                            STRING IP.Address)
                 then (
                   AVP SessionID = STRING Session.ID,
                   AVP IPAddress = STRING IP.Address
                 )
                 else (
                   releaseIPAddress(Address=STRING IP.Address),
                   AVP Error = "Unable an ASM. The remaining Actions transport objects from
     the return tree to setup session"
                 )
               )
               else ( AVP Error = "No IP Address" )
             )
             else ( AVP Error = "Permission Denied" )
           )
           else ( AVP Error = "User Profile Not Found" ) 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.

      The first situation is Policy Conflicts. 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 contradicting coní
          tradicting each other (which is a fault of the



A. Taal et al.           Expires: December 2001                [Page 20]

Internet Draft     Grammar for Policies in Generic AAA         June 2001 local administrators). adminisí
          trators).  A pushed policy doesn't have knowledge about the
          local policies.

      The second situation is that a

          2.  A pushed policy can define 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.

      The third situation is when we put an



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 computing computí
          ing power and/or bandwidth (for example a smartcard
      or some sort of hardware token). The machine could easily be swamped
          when policies are pushed from other machines.

      We advise

     That said, a policy can be pushed by storing it in a Request
     object.  A special message type should be used to indicate that more time a
     pushed policy has to be processed.  The Driving Policy for this
     request can decide whether the pushed policy is spent on defining accepted or not.
     If it is, the object containing the pushed policy could be passed
     to a ``Do's special FunctionCall which in turn extracts the policy and Don'ts''
      list for pushing
     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é Vollí
     brecht, "Generic AAA Architecture", RFC 2903, August 2000

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

     [AAAGEN] C. de Laat, J. Vollbrecht and D. Spence, "Structure of a
     Generic AAA server", Server", draft-irtf-aaaarch-generic-struct-00.txt,
      Februari
     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
      Physics and Astronomy department
      Utrecht
     Faculty of Science, Informatics Institute
     University
      Princetonplein 5
      3584 CC Utrecht of Amsterdam
     Kruislaan 403
     1098 SJ Amsterdam
     The Netherlands

     Phone: +31 30 2537556 20 5257590
     Fax:   +31 30 2537555 20 5257490
     Email: A.Taal@phys.uu.nl taal@science.uva.nl


     Guus Sliepen
     Physics and Astronomy department
     Utrecht University



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


      Guus Sliepen
      Physics and Astronomy department
      Utrecht University


     Princetonplein 5
     3584 CC Utrecht
     The Netherlands

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


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

     Email: aehemel@cs.uu.nl


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

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






















A. Taal et al.           Expires: December 2001 June 2002                    [Page 22]


-- 23]



----