view Side-By-Side changes
AAAARCH Research Group A. Taal
INTERNET DRAFT G. Sliepen
Category: Informational C.T.A.M. de Laat
March 2002 2004
A grammar for Policies in a Generic AAA Environment
<draft-irtf-aaaarch-generic-policy-02.txt>
<draft-irtf-aaaarch-generic-policy-04.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other docu-
ments at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
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: September 2002 2004 [Page 1]
Internet Draft Grammar for Policies in Generic AAA March 2002 2004
Abstract
In this document a formal language is presented to describe poli-
cies in the context concept of a generic AAA environment. We confine the
discussion to so called so-called Driving Policies. Policy is pre-
sented. A Driving Policy deter-
mines determines the behavior of an AAA Server server
(Authentication, Authorization, Accounting) when it is confronted
with a specific message type AAA message. The first part of this document
defines the AAA protocol. These role of a Driving Policies
should facilitate Policy and how it fits into the AAA Servers from various domains to work together
in order to satisfy requests from users for services that cross
those domains. Therefore,
concept. From the model presented results a restricted grammar for
Driving Policy must be able to
reference other policies, since Service Level Agreements Policies with other
domains are implemented as policies.
Other important features few predefined terms as possible. The
main task of a Driving Policy are the possibility
to call generic functions the AAA Server is equipped with, and the
possibility to delegate special tasks describe which pre-conditions
have to be checked before actions, needed to fulfill an incoming
AAA request, are delegated to so called Application Specific Modules. Modules, and how
to deal with the post-conditions of these actions. In the second
part the grammar for Driving Policies is presented accompanied by
the necessary remarks about the semantics.
Table of Contents
Status of this Memo . . . . . . . . . . . . . . . . . . . . . . 1
Copyright Notice . . . . . . . . . . . . . . . . . . . . . . . 1
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1. AAA environment . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The Use Case 'Satisfy request' Request' . . . . . . . . . . . . . . 5
2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . . 5 6
2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . . 5 6
2.4. The Use Case 'Authenticate user' User' . . . . . . . . . . . . . 6
2.5. The Use Case 'Authorize User' . . . . . . . . . . . . . . 6
2.6. The Use Case 'Perform Accounting' . . . . . . . . . . . . . .6 7
3. Driving Policies . . . . . . . . . . . . . . . . . . . . . . . 6 7
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 7
3.2. Formal model Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 10 9
3.2.2. Constants and variables . . . . . . . . . . . . . . . . 12 11
3.2.3. Object trees Procedures . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. Policy references . . . . . . . . . . . . . . . . . . . . 13
3.2.5. Actions . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13
4. Data Objects and Message Types . . . . . . . . . . . . . . . 15 14
5. Example Policy . . . . . . . . . . . . . . . . . . . . . . . 15 . . . 14
6. Ponder Other policy language languages . . . . . . . . . . . . . . . . . . . .18 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20 17
A. Taal et al. Expires: September 2002 2004 [Page 2]
Internet Draft Grammar for Policies in Generic AAA March 2002 2004
1. AAA environment
+----+ +---+ +---+
|User|<=======>|AAA|<===================================>|AAA|
|User|<======>|AAA|<===================================>|AAA|
+----+ +---+<========= =========>+---+
/\ /\ \\ // /\ /\
|| || || || || ||
|| \/ || || || \/
\/ +--+ || || \/ +--+
+---+ |PR| || || +---+ |PR|
|ASM| +--+ \/ \/ |ASM| +--+
+---+ +---+ +---+ +---+
|AAA|<=========>|AAA|
+---+ +---+
/\ /\ /\ /\
|| || || ||
|| \/ || \/
\/ +--+ \/ +--+
+---+ |PR| +---+ |PR|
|ASM| +--+ |ASM| +--+
+---+ +---+
Figure 1. The abstract view of a generic AAA environment
This section introduces an abstract view of a generic AAA environ-
ment [RFC2903], and what kind of components it consists of. can be distinguished.
Only those components are presented that are necessary to illustrate support
the discussion in this draft. An AAA Server server may receive a request
from an entity operating on a user's behalf. The contents of the request contains specifies
what kind of service the user wants. This request is evaluated by
the Rule Based Engine (RBE) of the AAA Server 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 the AAA protocol server understands (section
4) there exists a corresponding Driving Policy that is evaluated.
These Driving Policies are stored in the Policy Repository (PR).
Whether the request will be accepted or rejected depends on the
evaluation of the Driving Policy. In case the Driving Policy is
part of a distributed policy, For special tasks the AAA Server that receives the
request has to communicate with other AAA Servers in order to fully
evaluate the request. For special tasks the AAA Server (RBE)
resorts server
(RBE) resorts to generic functions or to so called Application
Specific Modules (ASMs).
Because Driving Policies can refer to local policies and to ASMs
for complex taks, the
The contents of the Policy Repository and the ASMs determine the
behavior of the AAA Server. A change of server (see fig.2). By changing the contents
of the PR and the ASMs will result in a different ASMs, the behavior of an AAA
Server. server can be
adapted to other kinds of requests, i.e. its behavior can be
modified. This feature should be dynamically supported to give
an Administrator the possibility to adjust the behavior of an AAA
Server
server without the necessity to recompile the AAA Server server code.
The four components shown in fig.2 make it possible to adhere to
the principles of Object Oriented design, like extendibility,
reusability, and encapsulation. With respect to encapsulation, the
A. Taal et al. Expires: September 2002 2004 [Page 3]
Internet Draft Grammar for Policies in Generic AAA March 2002 2004
+-------------+
|+-------------+
+| AAA request |
+-------------+
/\
/ \
/ \
/ \
/ \
/ Generic \
/ AAA \
/--------------\
+----------------+ +-------+
|+----------------+ |+-------+
+| Driving Policy | +| ASM |
+----------------+ +-------+
Figure 2. The AAA server
ASMs hide the low-level details of the service requested. This
allows for compact as possible Driving Policies.
2. Use Case Diagram
We will consider the role of a Driving Policy in response to a so
called AAA request. To illustrate the scope of this policy in the
generic AAA environment, we present a UML Use Case diagram for an
AAA request, fig. 3. As this is not the right document to fully
describe these Use Cases, only a concise description is presented.
+-+
+-+
| request Request/Reply +-----------------+ <<include>>
----- <=========> <============> | Satisfy request Request |============
| +-----------------+ ||
/ \ || \/
User || <<include>> +-----------------------+
|| | Lookup Driving Policy |
\/ +-----------------------+
+-------------------------+
===>| Evaluate Driving Policy |<==========
|| +-------------------------+ \\ <<extend>>
|| <<extend>> /\ \\ policy requires
|| policy requires || <<extend>> \\ authorization
|| accounting || policy requires \\
+------------+ || authentication \\
| Perform | +-------------------+ +----------------+
| Accounting | | Authenticate User | | Authorize User |
+------------+ +-------------------+ +----------------+
Figure 2. 3. Use Case diagram for an AAA request
We will consider the role of a Driving Policy
A. Taal et al. Expires: September 2004 [Page 4]
Internet Draft Grammar for Policies in response to Generic AAA March 2004
We define a so single Actor, called User, as an entity that speaks an
AAA request. To illustrate protocol. This generalized user wants a request to be
satisfied, the scope of this policy in Use Case 'Satisfy Request'. The association between
the
generic AAA environment, we present a UML Use Case diagram for a
future system of AAA Servers, fig. 2. As this is not the right
document to fully describe the Use Cases in fig. 2, only a concise
description is presented. We define a single Actor, called User,
as an entity that speaks the AAA protocol. This generalized user
wants a request to be satisfied, the Use Case 'Satisfy request'.
The relationship between the Actor and this Actor and this Use Case is a bi-direc-
tional association. bi-directional. It depicts the
participation of the Actor in the Use Case. This association is
bi-directional because the User expects an answer to his request.
At the highest level we have:
- Use Case: 'Satisfy request' Request'
- System: Network of AAA Servers
- Actors: User
- Precondition: none
In total we distinguish 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' and 'Evaluate Driving Policy',
there exists an include relationship. The functionality described
in 'Satisfy request' always includes the functionality of 'Lookup
Driving Policy' and 'Evaluate Driving Policy'. Those last two Use
Cases are mandatory for 'Satisfy request'. The extend relation-
ships are interpreted as conditional include relationships. The
Use Cases 'Authenticate user' User' and 'Authorize user', User', and æPerform
AccountingÆ 'Perform
Accounting' are only performed if some internal condition in the
Use Case 'Evaluate Driving Policy' requires it.
2.1. The Use Case 'Satisfy request' Request'
This Use Case will describe how an AAA Server server deals with an AAA
request issued by a device acting on the behalf of a real user,
and what answers towards the user can be given. Every request
is forwarded to the AAA Server server where the process to satisfy a
request actually starts. This AAA Server server may manage a Policy
Repository where the Driving Policy resides that needs evaluation.
The AAA Server server evaluates this policy and constructs the corres-
ponding response. A more detailed view of this Use Case would be
the
reveal a set of Use Cases associated with the different message
types of the AAA protocol. server understands (section 4).
A. Taal et al. Expires: September 2004 [Page 5]
Internet Draft Grammar for Policies in Generic AAA March 2004
2.2. The Use Case 'Lookup Driving Policy'
The AAA Server server must retrieve the Driving Policy that needs to be
evaluated before the request can be satisfied. As there There exists a
one-to-one ad and onto relationship between AAA requests and
Driving Policies, therefore, it is clear to the AAA Server server which
Driving Policy it has to retrieve. Any request will result in the
lookup of the corresponding Driving Policy in the local Policy
Repository (PR).
2.3. The Use Case 'Evaluate Driving Policy'
Policies can either be used in a stand-alone fashion or they can
refer to other policies. It is the task of the AAA Server to eval-
uate all policies necessary.
This task is delegated to the Rule Based Engine (RBE, see fig. 2). A complex situation occurs when a
request contains a policy that is pushed by the user. If this hap-
pens it must be clear what logical relation this policy has with
the stored Driving Policy, and whether this pushed policy contains
conditions the user is not authorized to push. Engine. The request may
contain objects (primitive data types ) types) to be sub-
stituted substituted for free
variables occurring in the Driving Policy. The RBE substitutes
everything at the proper place into the policy.
After If generic
functions or ASMs are referenced in the Driving Policy, the RBE has substituted all it knows, it
makes the call with the right arguments. The RBE decides whether
the policy is false, true or undecided yet.
This Use Case does not excludes the evaluation of other policies,
as ASMs might have their own policies.
It is the responsibility of the AAA Server server to keep track of all the
decision 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 User is the process of verifying the
proof of his identity. Authentication of the user User is only per-
formed if the Driving Policy under evaluation requires it. When
that is the case, the request must contain information about neces-
sary policy variables with respect to authentication. Furthermore,
the request may contain a certificate or password, his proof of
identity. In order to be sure the user 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 server performs authorization of a user's User's request, i.e.
whether the user User is allowed to obtain the requested service or
resource(s). Authentication and authorization is only performed
if the Driving Policy requires it. It is not strictly necessary to
perform authentication before authorization. There are cases where
the decision whether the request is authorized or not does not in
any way depend on information about the user. User.
A. Taal et al. Expires: September 2004 [Page 6]
Internet Draft Grammar for Policies in Generic AAA March 2004
2.6. The Use Case 'Perform Accounting'
Accounting is the collection of all the data about resource con-
sumption. Intermediate accounting or accounting indication informs
the User about currently used resources. The AAA Server server must
provide the information about which Resource Managers need to be
consulted. Resource Managers resorts to Meters that capture data
about resource consumption in the network.
3. Driving Policies
3.1. Introduction
As can be derived from the Use Case diagram in fig. 2, 3, the behavior
of an AAA Server 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-
essary for any future model.
There are several reasons to come with a formal model for a Driving
Policy. In this document present a grammar is presented. As a for Driving
Policy determines the behavior of an AAA Server into a large
extent, there Policies. 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 server. The Driving Polices together with the real ASMs determine
the specific functionality of an AAA Server, and therefore there will certainly be provisions for
that in the grammar. server. 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. it may reference main
functionality described by a Driving Policy residing at another AAA Server. In that case communication
between AAA Servers is involved during policy evaluation. The
request and response objects [section ??] must be suited to
accommodate the necessary information for remote policy evaluation.
This shows an interdependence between the formal model check certain
pre-conditions before calls to generic functions or ASMs are made,
and to take actions according to the
object types of a future AAA protocol.
Another important reason for a formal model responses of a policy is the need these calls.
Besides some simple arithmetic all complex tasks are delegated to allow pushed policies in
the generic AAA environment. An AAA Server server or
even to an application acting on behalf of ASM. If communication with other
AAA servers is required, a user should be allowed call to
present policies in a request. Obviously a standard protocol generic function or
language must exist for those policies so that the parties involved
agree upon the contents.
Since the AAA concept (architecture and protocol) ASM is
made. In case a complicated
one, there exists request contains a large need for simulation. As the behavior of
an AAA Server reference to a policy, this
task is policy driven, the contents of the Policy Reposi-
tory will be reflected in the outcome of also delegated to a simulation. The generic function or to an ASM. This
means that the grammar does not need to provide for simulation comes from the hope a policy
reference or a call to proof the decidability of
policies in a distributed, generic remote AAA system.
3.2. Formal model
There can be many definitions of server.
As a policy grammar. The grammar we
propose here is NOT presented as an official AAA policy grammar.
However, we present it to pinpoint consequence the elements, which will most
likely be part of an official AAA policy grammar. The grammar
is can be kept as concise as possible, so that policies according to this possible.
3.2. Grammar
The 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 propose here achieve its generic property through
being minimal specified. We also present this grammar to facilitate the
discussion about AAA
policies, and to document this language in order to explain the
results of a possible simulation of a generic AAA system. policies. The notation of the grammar below
is in EBNF (Extended Backus Naur Formalism), terminal symbols are
placed between double quotes:
Policy
DrivingPolicy ::= "if" "(" Condition ")" "then" "(" ActionList ")"
"else" "(" ActionList ")"
Condition ::= BoolExpr
A. Taal et al. Expires: September 2004 [Page 7]
Internet Draft Grammar for Policies in Generic AAA March 2004
BoolExpr ::= Bool
| Var
| ComputedBoolean
| {Var "="}? Procedure
| Policy ComputedBoolean
| 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 ProcedureName "(" ARGList ")"
ARGList ::= {ARG {"," ARG}*}?
ARG ::= Var "=" Bool
| Var "=" String
| ComputedBoolean
| Var "=" NonBooleanExpr
| Var "=" Procedure
ActionList ::= {Action {";" Action}*}?
Action ::= Var "=" Bool
| Var "=" ComputedBoolean
| Var "=" NonBooleanExpr
| {Var "="}? Procedure
| Policy
ComputedBoolean
ComputedBoolean ::= "(" NonBooleanExpr ComparisonOperator
NonBooleanExpr
| "exists" Var ")"
ComparisonOperator ::= "=="
| ">"
| ">="
| "<"
| "<="
| "!="
NonBooleanExpr ::= Int
| Float
| String
| Var
| Procedure
| UnaryArithmeticOperator NonBooleanExpr
| "(" NonBooleanExpr BinaryArithmeticOperator
NonBooleanExpr ")"
UnaryArithmeticOperator ::= "-"
BinaryArithmeticOperator ::= "+"
| "-"
| "/"
| "*"
| "%"
| "&"
| "|"
ActionList ::= {Action {";" Action}*}?
A. Taal et al. Expires: September 2002 2004 [Page 8]
Internet Draft Grammar for Policies in Generic AAA March 2002 2004
Action ::= Var "=" Bool
| Var "=" String
| Var "=" ComputedBoolean
| Var "=" NonBooleanExpr
| Procedure
| DrivingPolicy
Var ::= Source {"." Source}*
Source ::= Identifier
PolicyName ::= "::" Identifier
FunctionName ::= "." Identifier
Hostname
ProcedureName ::= String Identifier
Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*"
String ::= "\"[^"\n]*\""
Int ::= "-?[0-9]+"
Float ::= "-?[0-9]+\.[0-9]*(E-?[0-9]+)?"
Bool ::= "(true|false)"
A Driving Policy (Driving Policy) can be viewed as an if-then-else con-
struction. structure.
The 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 then-
part and the else-part consist of a list of Actions (ActionList).
Actions are tasks to be performed, and their execution is guarded
by the Condition. The Actions in the then-part are executed when
the Condition is true, and the Actions in the else-part are exe-
cuted when the Condition is false. To a Driving Policy we also
attach a Boolean value. We define a Driving Policy to be true if
and only if the Condition is true, and the Actions of the then-part are
successfully executed. true. A Driving Policy is said to be
false if and only if the Condition is false, and the Actions in the else-part are
successfully executed. false. In all other
situations, the state of the Driving 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. (see section 3.3).
Driving Policies can be nested in both Conditions as well as Actions. ActionLists. A Driving 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 subexpressions of
a 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
nesting.
Two other components of the model that can have a truth value are
a PolicyRef and a 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 (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.
policy.
The component FunctionCall Procedure can be interpreted as a function call to
an Application Specific Module (ASM), or more general a call of to a
generic library function the AAA server is equipped with. An
important concept is the result of a PolicyRef and a FunctionCall.
With respect to the result their is no 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
In the next sections we will explain the syntax of the grammar
accompanied with remarks about the semantics of that the grammar.
3.2.1. Conditions
A Condition is defined as an arbitrary Boolean formula, i.e. we
don't make the restriction to a formula in DNF (Disjunctive Normal
Form) or CNF (Conjunctive Normal Form) notation. The introduction
A. Taal et al. Expires: September 2004 [Page 9]
Internet Draft Grammar for Policies in Generic AAA March 2004
of brackets avoids any ambiguity, without the need to define a
precedence rule for the logical AND- ("&&") and OR-operator ("||").
It is desirable to define how a Condition is evaluated, or in other
words the if-statement is said to be deterministic. Here we
propose to follow the C language, which also guarantees that `&&'
and `||' are evaluated left to right. For an OR-expression it
holds that the right operand is not evaluated if the left operand
evaluates to true. The same holds for the AND-expression if the
left operand evaluates to false. This also implies that different
parts of a Condition can not be evaluated in parallel. From
parallel evaluation follows that the requester should be satisfied
with any result making the Condition true or false. 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 false, unless
concurrency operators.
According to the above definition the following two Policies operators are
equivalent:
1) if(
if ( C1 ) then ( A11 ) else ( A12 )
&&
if ( C2 ) then ( A21 ) else ( A22 )
)
then ( A00 ) else ( A01 )
2) if( C1 )
then(
if( C2 ) then( A11 ; A21 ; A00 ) else( A11 ; A22 ; A01 )
)
else ( A12 ; A01 )
A. Taal et al. Expires: September 2002 [Page 10]
Internet Draft Grammar for Policies in Generic AAA March 2002 introduced.
A Condition, or Boolean expression, is composed of six four different
types of operands (literals): operands: Bool, Var, ComputedBoolean,
Procedure, Policy, and BoolExpr. Procedure or ComputedBoolean.
The use of a variable (Var), see below, implies that the value
referenced can be interpreted as a Boolean value. The same holds
for the return value of a Procedure when applied as a operand.
A ComputedBoolean is a comparison between a left and right hand
expression.
An important aspect example 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 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 Driving Policy for authentication illustrates some
of the correspon-
ding reply begins concepts dealt with the reserved word "Reply".
A reference to a policy (PolicyRef) opens the possibility to reuse
local policies (policies in the same Policy Repository) above, 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 the semantics of policy references is Var
and Procedure:
if( ASM::Authenticator.checkPassword(
Request::AuthenticationData.UserID,
Request::AuthenticationData.Passwd )
) then (...) else (...)
Herein, the need Condition consists 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 (section 4). The
other type, FunctionCall, may be interpreted as a function Procedure, a call to an Application Specific Module (ASM), or as ASM
with the name Authenticator, which has a call public method
checkPassword. Two arguments, both Vars, have to a library
function. Both Procedures, a PolicyRef and a FunctionCall, are
equivalent in be passed. As
the sense Vars start with the reserved word 'Request', the RBE knows
that the result is an object tree. If an
assignment is made all parts of this result tree values referenced are accessible located in the remaining Policy. Whether or not an assignment is made, Request. The dot-
structure indicates the
truth value sub-tree of the Procedure Request. It is implicitly used to determine the truth value of assumed
that the Policy it is
contained in. The only reason Procedure returns a different syntax is applied for
PolicyRef and FunctionCall, is to indicate that different APIs
(protocols) are involved for PolicyRefs and FunctionCalls,
respectively. Boolean value.
An example of an `Authentication Policy' illustrates some of alternative, wherein the
concepts dealt with above: Condition consists of a Computed
Boolean, may look like:
if( Query = getPassword( userid = Request.UserID )
&&
Request.PassW ( Request::AuthenticationData.Passwd == Query.PassW
ASM::Authenticator.getPassword(
Request::AuthenticationData.UserID )
)
) then (...) else (...)
Herein, the Condition compares the password supplied in the request
with the password of the user stored in the authentication data-
base. The ASM function getPassword() retrieves the password cor-
responding to the username that has been supplied as an argument.
This argument refers to a variable called "UserID" in the Request.
By making the assignment "Query=getPassword(...)", the password in
the return tree can be referred to. This is done in the right hand
side of the Condition.
A. Taal et al. Expires: September 2002 2004 [Page 11] 10]
Internet Draft Grammar for Policies in Generic AAA March 2002
A useful feature is 2004
As stated above, the operator "exists" in combination with an
object if-statement is said to be deterministic, and
as a ComputedBoolean. This allows checking if a certain
object exists such there is no need to allow nesting of Driving Policies in a return tree or Request:
Condition. Take for instance the following nested Driving Policy:
if( exists Request.Bandwidth && Request.Bandwidth >= 10 A || Pol )
then( a0 )
then(...) else (...) ( a1 )
with Pol: if( B ) then( b0 ) else ( b1 ).
Adopting the C convention this Driving Policy is equivalent to
if( A ) then( a0 )
else ( if( B ) then( b0 ; a0 ) else( b1 ; a1 ) )
3.2.2. Constants and variables
The grammar allows the use of constants and variables, but like
in other scripting languages (e.g. JavaScript) the grammar does not
provide for type checking. Therefore, the use of variables and
constants of different types in the same expression may result in
an error state. For example the multiplication of two variables, one representing a string and
the other representing with a
floating point number results in an abortion of the evaluation.
3.2.3. Object trees
As mentioned above, variables
Variables (Vars) refer to a member of an object tree. The
corresponding dot-structure indicates an unique path to a node of
the object tree. We use the following definitions. A node of an
object tree is a leaf if it has no children. All other nodes are
internal nodes. If a Var refers to a leaf of an object tree, it
refers to a primitive type, like an int, float or string value.
A reference to an internal
node means that the Var refers to an object, i.e. an sub-tree of
the object tree starting at that specific internal node.
Take for instance the Authentication Request/Reply (section 4)
Request: Reply:
Identity Answer
AuthenticationData
Suppose the Identity object in the request contains a string called
UserID. This member of the Request may be represented as a Var
(variable) with the dot-structure: Request.Identity.UserID.
A Var refers to an empty object tree if the head of the
corresponding dot-structure is does not begin with the reserved word "Request"
'Request' or
"Reply", '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
A relative simple implementation of a RBE suffices if we propose restrict
ourselves to Vars representing a leaf of an object tree, i.e. a
primitive value. In case Vars representing an internal node are
desired, Vars refer to objects to be created by the RBE, and some
additional remarks about the following semantics of assignments with variables.
variables should be made.
Consider the assignment of the form Var = Var with corresponding
dot-structure A.B.C = D.E.
Four different cases can be distinguished.
1) The left and right hand side both refers to an existent object
tree, i.e. a non-empty object tree. Then the assignment means that
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 obtains the value of leaf E.
A. Taal et al. Expires: September 2002 [Page 12]
Internet Draft Grammar for Policies in Generic AAA March 2002
2) The left-hand side is an existent object tree whereas the
right-hand side is an empty object tree. This means that the
sub-tree of the tree at the left-hand side starting at node C is
deleted. Node C becomes
a leaf with no value.
3) The left-hand side is an empty object tree whereas the
right-hand side is an existent object tree. This is the
declaration of a new object tree.
A. Taal et al. Expires: September 2004 [Page 11]
Internet Draft Grammar for Policies in Generic AAA March 2004
4) Both sides of the assignment refer to an empty object tree.
There is no need to define this as an error. As nothing has to be
done, such an assignment might be ignored.
It is important to notice that all assignments are assignments by
value and NOT by reference. Assignment by reference would lead to
undesirable effects. The assignment A.B.C = A.B would result in an
object tree with node C pointing to itself.
3.2.4. Policy references
There
A variable, Var, is a difference between a policy reference (PolicyRef) to a
local policy dot-structure and one to a remote policy. A reference to a remote
policy will initiate communication provides the RBE with another AAA Server. As all
communication among AAA Servers will proceed via the AAA protocol,
only predefined message types are used. Therefore,
information where the name part
(PolicyName) value referenced can be retrieved. The
object tree of the policy reference is limited to request always starts with the name of one reserved word
'Request', whereas the object tree of these predefined message types. This restriction does not hold
for references to locally stored policies. Such a reference has
only a restriction the corresponding reply begins
with respect to the host name used. If reserved word 'Reply'.
Consider the
PolicyReference refers to following example of an AAA request in XML:
<Request type="Service" >
<ServiceData>
<SwitchData>
<Source>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>500</Bandwidth>
<StartTime>12:45</StartTime>
<Duration>45</Duration>
</SwitchData>
</ServiceData>
</Request>
A variable 'Request::ServiceData.SwitchData.Bandwidth' indicates a local policy,
unique path to the PolicyName indicates
which policy should node <Bandwidth>.
3.2.3. Procedures
A Procedure may be retrieved from interpreted as a function call to an Application
Specific Module (ASM), or as a call to a library function the Policy Repository.
Generic AAA server is equipped with. If an assignment is made the
return value is accessible in the remaining policy. If the
Procedure is part of a Condition, it is supposed that the return
value is a Boolean. In general PolicyRefs are that case the truth-value of the Procedure
is implicitly used to determine the truth-value of the Condition,
whether or not interchangeable with an assignment is made.
A Procedure is also used to reference to other policies.
Referencing a local policy, stored in the policies
they refer to.
3.2.5. local PR, might be
implemented as a call to a generic function or to an ASM. If a
remote policy is referenced, a policy stored in the PR of another
AAA server, communication with another AAA server during policy
evaluation is needed. A future AAA protocol (section 4) should
provide for request/reply objects in order to support referencing
remote policies. Such a reference might also be implemented as a
call to a generic function or to an ASM.
A. Taal et al. Expires: September 2004 [Page 12]
Internet Draft Grammar for Policies in Generic AAA March 2004
3.2.4. Actions
In order to reduce unexpected effects to a minimum and make sure
that different AAA Servers servers always exhibit the same behavior, we
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.
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
The introduction of concurrency operators 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
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( firewallready() )
then ( openfirewall() )
else (...)
&&
if( packetready() )
then( sendpacket() )
else ( closefirewall() )
)
then (...) else (...).
The introduction of concurrency operators in the grammar opens grammar may open
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
Driving Policy might refer to objects that are missing. A
FunctionCall,
Procedure, for example getPassword(), getPassword(..), might generate an error,
because for example the password is not found in the database, or fail to respond
because the database 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 a
division by zero. As Vars might be of different types,
incompatibilities might occur during evaluation of an expression,
like a string multiplied by a float.
Suppose that errors do not break or interfere with evaluation. If
in the above example (previous section) openfirewall() fails,
then continuing the evaluation of the Condition will certainly
make sendpacket() fail as well. In this example it is
desirable that the evaluation stops after Because the first error.
So, when an error that is grammar does not caught by whatever construction in
the Policy occurs, the RBE either has to ignore the error
and continue or abort evaluation. As
provide for exception handling is not
part of the grammar, handling, the most safe strategy is to abort evaluation.
The administrator can make sure that the Policies are constructed
in such a way that
the occurrence evaluation of the policy after error states are limited.
This occurrence. Error codes
might be done by checking the input for Procedures if it meets
A. Taal et al. Expires: September 2002 [Page 14]
Internet Draft Grammar for Policies in Generic AAA March 2002
the precondition. Take for instance a Service request for band-
width that contains an object ServiceData. A precondition for the
FunctionCall defined to inform the appropriate ASM, might be that the requested
bandwidth is at least 10 and at most 100. Then a Driving Policy
may look like:
if( exists Request.ServiceData.Bandwith
&&
Request.ServiceData.Bandwidth >= 10
)
then
(
if( Request. ServiceData.Bandwidth <= 500 )
then(...)
else(Reply.Answer.Message = "Requested bandwidth too large" )
)
else( Reply.Answer.Message = "Requested bandwidth too small" )
4. Data Objects and Message Types
This section describes the need for a specification of requester about the message
types and of top level objects to be carried in a future AAA
protocol. For each message type there should be a corresponding
Driving Policy. Message types occur as a Request Reply couple.
Such a list abortion of 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 its
request. In any case it is sent to an AAA Server necessary to obtain
a remote policy. It would contain define a data object, Policy Reference.
The corresponding special 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 to
inform the AAA Actors. As a result pre- and postconditions can be
abstracted requester that policy evaluation has aborted.
There are several possibilities to guide reduce the construction occurrence of the corresponding Driving
Policies.
5. Example Policy
In this section we present a Driving Policy
errors. With respect to deal with an AAA
Authentication request. A user issues an Authentication request
containing the following objects: an Identity object and an
AuthenticationData object. The AAA server recognizes failure of Procedures, 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
administrator can make sure that the corresponding Driving
Policy from the PR. Assume, the AAA server acts as Policies are
constructed in such a Key
Distribution Center (KDC) for way that the Kerberos authentication protocol.
The Kerberos protocol is comprised occurrence of three subprotocols:
a) Authentication Service Exchange; error states are
limited. This might be done by checking the client sends a Kerberos
Authentication Service Request (KRB_AS_REQ )
b) Ticket-Granting Service Exchange; input for Procedures
if it meets the client sends precondition. Take for instance a Kerberos
Ticket-Granting Service Request (KRB_TGS_REQ )
c) Client/Server Exchange; request
for bandwidth that contains an object ServiceData. A precondition
for the client sends call to the server a Kerberos
Application Request (KRB_AP_REQ)
The following policy appropriate ASM, might be that the requested
bandwidth is at least 10 and at most 1000. Then a Driving Policy for an incoming
Authentication request:
if
(
may look like:
if( exists Request.AuthenticationData.Protocol.Name )
then( )else( Reply.Answer.Type = MISSING_DATA ,
Reply.Answer.Message = "Missing Protocol.Name" (Request::ServiceData.SwitchData.Bandwidth >= 10) )
&&
then
(
if( Request.AuthenticationData.Protocol.Name == "Kerberos" ( Request::ServiceData. SwitchData.Bandwidth <= 1000 )
then( )
then(...)
else( Reply = Authentication@131.211.32.73(
Identity = Request.Identity ,
AuthenticationData = Request.AuthenticationData )
&&
if( exists Request.AuthenticationData.Protocol.MsgType )
then( )else( Reply.Answer.Type = MISSING_DATA ,
Reply.Answer.Message Reply::Answer.Message = "Missing Protocol.MsgType" )
&&
if( Request.AuthenticationData.Protocol.MsgType == KRB_AS_REQ "Bandwidth too large" )
then(
)
else( Reply.Answer.Type Reply::Answer.Message = UNKNOWN_DATA ,
Reply.Answer.Message = "Unknown MsgType" )
)
then
(
// Action 1
if
( exists Request.Identity.UserName
&&
exists Request.AuthenticationData.ServerName
&&
exists Request.AuthenticationData.PreAuthentication "Bandwidth too small" )
A. Taal et al. Expires: September 2002 2004 [Page 16] 13]
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
;
// Action 1.3
Reply.Answer.AuthenticationData.TGT = KRBReply.TGT
)
else( Reply.Answer.Type = MISSING_DATA,
Reply.Answer.Message = "AuthenticationData incomplete" )
;
...
)
else
( ... )
In the above Driving Policy a Condition of four ANDed Policies is
evaluated. Here we assume the following precondition: a proper AAA
Authentication request containing an Identity object and an
AuthenticationData object. Furthermore, it is assumed that the
last object contains a Protocol object. About the contents of
these objects no additional assumptions are made. The first
literal of the 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. 2004
If not, the Actions in the
else-part of the first literal AAA requests are executed. These Actions add
data to the reply object, defined by setting XML, XML Schema's or DTDs might be
used. An XML schema provides a means for defining the variables Type structure,
content and Message the semantics of an XML document. This eliminates
errors due to the object Answer. bad contents of a request.
The first Action RBE might be interpreted check division or incompatibilities in arithmetic
expressions, as well as
assigning terminate policy evaluation after time out
of a function call.
4. Data Objects and Message Types
This section describes the variable Type to need for a predefined integer called
MISSING_DATA. In case specification of the first literal is found message
types and the top level objects to be false, carried in a future AAA
protocol. As the
Condition number of different AAA servers is false and almost
unlimited, the Actions in same holds for the else-part number of the Driving
Policy are executed. The second literal different
Request/Reply pairs. An AAA server providing bandwidth has a reference to a
remote policy (PolicyRef) as little
in common with an Action. This Action is executed
if AAA server for the authentication protocol requested differs from ordering of a pizza.
A new technique like WSDL (Web Services Description Language) opens
the Kerberos
protocol. It entails an AAA request issued possibility to another cope with the expected diversity in AAA Server
(131.211.32.73). Information
Request/Reply pairs. WDSL [WSDL] can be used to specify in detail
information about what kind of the service an AAA request has to
be send, is provided by server delivers such as the name-part
type of data it requires (Request) and the PolicyRef, which
equals one type of data it produces
(Reply). Applying WSDL, the specification of the message types defined. Two arguments are passed
to and
the policy reference, top level objects can be limited to those messages needed for
the Identity and intercommunication between AAA servers.
Such a list of message types should certainly contain:
a) Authorization Request/Reply
b) Authentication Request/Reply
c) Policy Request/Reply
d) Policy Evaluation Request/Reply
e) Error Reply
For instance, a Policy Request is sent to an AAA server to obtain
a remote policy. It should contain a Policy Reference object.
The corresponding Reply should contain a Policy data object.
5. Example
In this section we present a simple Driving Policy in XML to deal
with an AAA request for bandwidth. A User issues an AAA request
containing the following objects, an AuthenticationData
object form the original request. object, and
a ServiceData object. 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 correspinding Driving Policy. This
Action is a Policy which Condition checks asks for
the existence authentication of some the requester before the service will be
delivered
A. Taal et al. Expires: September 2002 2004 [Page 17] 14]
Internet Draft Grammar for Policies in Generic AAA March 2002
variables (objects), like UserName, ServerName, and
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. 2004
The remaining
Actions transport objects from the return tree to the reply.
6. Ponder policy language Request:
<?xml version="1.0" encoding="UTF-8"?>
<Request version="0.1" type="Service" >
<AuthenticationData>
<Identity>Joe</Identity>
<Password>aaa</Password>
</AuthenticationData>
<ServiceData>
<SwitchData>
<Source>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>500</Bandwidth>
<StartTime>12:45</StartTime>
<Duration>45</Duration>
</SwitchData>
</ServiceData>
</Request>
The corresponding Reply:
<?xml version="1.0" encoding="UTF-8"?>
<Reply version="0.1" type="Service" >
<Answer><Message></Message></Answer>
</Reply>
The language according to the presented grammar describes policies
that can be implemented in for instance the Ponder policy language
[PONDER]. Driving Policies should be implemented as obligation
policies. In Ponder an obligation policy specifies the actions
that must be performed by managers within the system when certain
events occur. In the context of Driving Policies, an event is an AAA server recognizes the request issued by an user.
In case of 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 role, a composite policy in which all the policies have the
same subject. In our case the subject is an automated component
called RBE. A role is also the choice if the Driving Policy is not
nested, but has an non-empty ActionList in the then-part. Take for
instance Service request and
draws the following corresponding Driving Policy:
if( Query = getPassWord( userid = Request.UserID )
&&
Request.PassW = Query.PassW
)
then( action11( ) ; action12( Policy from the PR:
if
( ASM::Authenticator.Authenticate(
Request::AuthenticationData.Identity,
Request::AuthenticationData.Password )
)
else( action21(
then
( if
( ASM::RM.CheckConnection(
Request::ServiceData.SwitchData.Source,
Request::ServiceData.SwitchData.Destination ) ; action22(
)
then
( if
( (Request::ServiceData.SwitchData.Bandwidth <= 1000 )
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
then
(
R1 = authentication( /Request, /Reply, . . . ASM::RM.BoD(
Request::ServiceData.SwitchData.Source,
Request::ServiceData.SwitchData.Destination,
Request::ServiceData.SwitchData.Bandwidth,
Request::ServiceData.SwitchData.StartTime,
Request::ServiceData.SwitchData.Duration ) @ /RBE
A. Taal et al. Expires: September 2002 2004 [Page 18] 15]
Internet Draft Grammar for Policies in Generic AAA March 2002
In general a nested Driving Policy can always be written as a set
of simple Policies, i.e. a non-nested Policy with an empty
ActionList in the then-part.
For example, a Policy as a literal:
if( A && 2004
;
if( B ) then( b11 ) else( b21 ( R1 < 0 ) ) then( a11
then
( Reply::Answer.Message = "UNKNOWN failure occurred"
) else( a22
else
( Reply::Answer.Message = "Request successful"
)
is equivalent to the following set of Policies:
1) if( A && B
) then( b11 ; a11
else
( Reply::Answer.Message = "Bandwidth too small"
)
2) if( A && !B
) then( b21 ; a21
else
( Reply::Answer.Message = "Bad source or destination"
)
3) if( !A
) then( a21
else
( Reply::Answer.Message = "Authentication failed"
)
Here it is assumed that
An Action like, Reply::Answer.Message = "Authentication failed",
instructs the evaluation of RBE to add a Condition is stopped as
soon its truth-value is determined. Therefore, if A turns out text node to
be false, B the Reply that is not evaluated.
Each of returned
to the simple Policies can User.
6. Other policy languages
The language according to the presented grammar describes policies
that might be implemented as a separate
obligation in several policy languages. However the
concept of a Driving Policy presented in this paper (fig. 2)
justifies the definition of a role, as outlined above.
A. Taal et al. Expires: September 2002 [Page 19]
Internet Draft Grammar special restricted grammar for Policies in Generic
Driving Policies. The concept chosen allows for a policy
language with as few predefined terms as possible as the tasks an
AAA March 2002 server has to perform are mainly delegated to Application
Specific Modules or generic AAA functions.
References
[RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Voll-
brecht, "Generic AAA Architecture", RFC 2903, August 2000
[PONDER] http://www-dse.doc.ic.ac.uk/research/policies/ponder.html
[WSDL] http://www.w3.org/TR/wsdl
A. Taal et al. Expires: September 2004 [Page 16]
Internet Draft Grammar for Policies in Generic AAA March 2004
Authors' Addresses
Arie Taal
Faculty of Science, Informatics Institute,
University of Amsterdam
Kruislaan 403
1098 SJ Amsterdam
The Netherlands
Phone: +31 20 5257590
Fax: +31 20 5257490
Email: taal@science.uva.nl
Guus Sliepen
Physics and Astronomy department
Utrecht University
Princetonplein 5
3584 CC Utrecht
The Netherlands
Phone: +31 30 2537724
Fax: +31 30 2537555
Email: G.Sliepen@phys.uu.nl
Cees de Laat
Faculty of Science, Informatics Institute,
University of Amsterdam
Kruislaan 403
1098 SJ Amsterdam
The Netherlands
Phone: +31 20 5257590
Fax: +31 20 5257490
Email: delaat@science.uva.nl
A. Taal et al. Expires: September 2002 2004 [Page 20] 17]
----