One document matched: draft-irtf-aaaarch-generic-policy-04.txt
Differences from draft-irtf-aaaarch-generic-policy-03.txt
AAAARCH Research Group A. Taal
INTERNET DRAFT G. Sliepen
Category: Informational C.T.A.M. de Laat
March 2004
A grammar for Policies in a Generic AAA Environment
<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.
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 2004 [Page 1]
Internet Draft Grammar for Policies in Generic AAA March 2004
Abstract
In this document the concept of a so-called Driving Policy is pre-
sented. A Driving Policy determines the behavior of an AAA server
(Authentication, Authorization, Accounting) when it is confronted
with a specific AAA message. The first part of this document
defines the role of a Driving Policy and how it fits into the AAA
concept. From the model presented results a restricted grammar for
Driving Policies with as few predefined terms as possible. The
main task of a Driving Policy is to describe which pre-conditions
have to be checked before actions, needed to fulfill an incoming
AAA request, are delegated to Application Specific Modules, and how
to deal with the post-conditions of these actions. In the second
part the grammar for Driving Policies is presented accompanied by
the necessary remarks about 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' . . . . . . . . . . . . . . 5
2.2. The Use Case 'Lookup Driving Policy' . . . . . . . . . . . 6
2.3. The Use Case 'Evaluate Driving Policy' . . . . . . . . . . 6
2.4. The Use Case 'Authenticate User' . . . . . . . . . . . . . 6
2.5. The Use Case 'Authorize User' . . . . . . . . . . . . . . 6
2.6. The Use Case 'Perform Accounting' . . . . . . . . . . . . . 7
3. Driving Policies . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Constants and variables . . . . . . . . . . . . . . . . 11
3.2.3. Procedures . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.4. Actions . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3. Errors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. Data Objects and Message Types . . . . . . . . . . . . . . . 14
5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Other policy languages . . . . . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Taal et al. Expires: September 2004 [Page 2]
Internet Draft Grammar for Policies in Generic AAA March 2004
1. AAA environment
+----+ +---+ +---+
|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 can be distinguished.
Only those components are presented that are necessary to support
the discussion in this draft. An AAA server may receive a request
from an entity operating on a user's behalf. The request specifies
what kind of service the user wants. This request is evaluated by
the Rule Based Engine (RBE) of the AAA server where a Driving
Policy resides that needs to be evaluated with respect to the
request. For each message type the AAA server understands (section
4) there exists a corresponding Driving Policy that is evaluated.
These Driving Policies are stored in the Policy Repository (PR).
Whether the request will be accepted or rejected depends on the
evaluation of the Driving Policy. For special tasks the AAA server
(RBE) resorts to generic functions or to so called Application
Specific Modules (ASMs).
The contents of the Policy Repository and the ASMs determine the
behavior of the AAA server (see fig.2). By changing the contents
of the PR and the ASMs, the behavior of an AAA server can be
adapted to other kinds of requests, i.e. its behavior can be
modified. This feature should be dynamically supported to give
an Administrator the possibility to adjust the behavior of an AAA
server without the necessity to recompile the AAA server code.
The four components shown in fig.2 make it possible to adhere to
the principles of Object Oriented design, like extendibility,
reusability, and encapsulation. With respect to encapsulation, the
A. Taal et al. Expires: September 2004 [Page 3]
Internet Draft Grammar for Policies in Generic AAA March 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/Reply +-----------------+ <<include>>
----- <============> | Satisfy Request |============
| +-----------------+ ||
/ \ || \/
User || <<include>> +-----------------------+
|| | Lookup Driving Policy |
\/ +-----------------------+
+-------------------------+
===>| Evaluate Driving Policy |<==========
|| +-------------------------+ \\ <<extend>>
|| <<extend>> /\ \\ policy requires
|| policy requires || <<extend>> \\ authorization
|| accounting || policy requires \\
+------------+ || authentication \\
| Perform | +-------------------+ +----------------+
| Accounting | | Authenticate User | | Authorize User |
+------------+ +-------------------+ +----------------+
Figure 3. Use Case diagram for an AAA request
A. Taal et al. Expires: September 2004 [Page 4]
Internet Draft Grammar for Policies in Generic AAA March 2004
We define a single Actor, called User, as an entity that speaks an
AAA protocol. This generalized user wants a request to be
satisfied, the Use Case 'Satisfy Request'. The association between
the Actor and this Use Case is bi-directional. It depicts the
participation of the Actor in the Use Case. This association is
bi-directional because the User expects an answer to his request.
At the highest level we have:
- Use Case: 'Satisfy Request'
- System: Network of AAA Servers
- Actors: User
- Precondition: none
In total we distinguish six Use Cases:
- 'Satisfy Request'
- 'Lookup Driving Policy'
- 'Evaluate Driving Policy'
- 'Authenticate User'
- 'Authorize User'
- 'Perform Accounting'
Between the Use Case 'Satisfy Request' and 'Lookup Driving Policy',
as well as between 'Satisfy request' and 'Evaluate Driving Policy',
there exists an include relationship. The functionality described
in 'Satisfy request' always includes the functionality of 'Lookup
Driving Policy' and 'Evaluate Driving Policy'. Those last two Use
Cases are mandatory for 'Satisfy request'. The extend relation-
ships are interpreted as conditional include relationships. The
Use Cases 'Authenticate User' and 'Authorize User', and 'Perform
Accounting' are only performed if some internal condition in the
Use Case 'Evaluate Driving Policy' requires it.
2.1. The Use Case 'Satisfy Request'
This Use Case will describe how an AAA server deals with an AAA
request issued by a device acting on the behalf of a real user,
and what answers towards the user can be given. Every request
is forwarded to the AAA server where the process to satisfy a
request actually starts. This AAA server may manage a Policy
Repository where the Driving Policy resides that needs evaluation.
The AAA server evaluates this policy and constructs the corres-
ponding response. A more detailed view of this Use Case would
reveal a set of Use Cases associated with the different message
types of the AAA server understands (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 must retrieve the Driving Policy that needs to be
evaluated before the request can be satisfied. There exists a
one-to-one and onto relationship between AAA requests and
Driving Policies, therefore, it is clear to the AAA server which
Driving Policy it has to retrieve. Any request will result in the
lookup of the corresponding Driving Policy in the local Policy
Repository (PR).
2.3. The Use Case 'Evaluate Driving Policy'
This task is delegated to the Rule Based Engine. The request may
contain objects (primitive data types) to be substituted for free
variables occurring in the Driving Policy. The RBE substitutes
everything at the proper place into the policy. If generic
functions or ASMs are referenced in the Driving Policy, the RBE
makes the call with the right arguments. The RBE decides whether
the policy is false, true or undecided yet.
This Use Case does not excludes the evaluation of other policies,
as ASMs might have their own policies.
It is the responsibility of the AAA server to keep track of all the
decision processes.
2.4. The Use Case 'Authenticate User'
The authentication of the User is the process of verifying the
proof of his identity. Authentication of the User is only per-
formed if the Driving Policy under evaluation requires it. When
that is the case, the request must contain information about neces-
sary policy variables with respect to authentication. Furthermore,
the request may contain a certificate or password, his proof of
identity. In order to be sure the User is the one he says he is,
his proof of identity needs to be verified.
2.5. The Use Case 'Authorize User'
An AAA server performs authorization of a User's request, i.e.
whether the User is allowed to obtain the requested service or
resource(s). 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.
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 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. 3, the behavior
of an AAA server is policy driven with respect to a request. In
this section we present a grammar for Driving Policies. There is a
tight relationship between the grammar and the architecture of an
AAA server. The Driving Polices together with the ASMs determine
the specific functionality of an AAA server. The main
functionality described by a Driving Policy is to check certain
pre-conditions before calls to generic functions or ASMs are made,
and to take actions according to the responses of these calls.
Besides some simple arithmetic all complex tasks are delegated to
the generic AAA server or to an ASM. If communication with other
AAA servers is required, a call to a generic function or ASM is
made. In case a request contains a reference to a policy, this
task is also delegated to a generic function or to an ASM. This
means that the grammar does not need to provide for a policy
reference or a call to a remote AAA server.
As a consequence the grammar can be kept as concise as possible.
3.2. Grammar
The grammar we propose here achieve its generic property through
being minimal specified. We present this grammar to facilitate the
discussion about AAA policies. The notation of the grammar below
is in EBNF (Extended Backus Naur Formalism), terminal symbols are
placed between double quotes:
DrivingPolicy ::= "if" "(" Condition ")" "then" "(" ActionList ")"
"else" "(" ActionList ")"
Condition ::= BoolExpr
A. Taal et al. Expires: September 2004 [Page 7]
Internet Draft Grammar for Policies in Generic AAA March 2004
BoolExpr ::= Bool
| Var
| {Var "="}? Procedure
| ComputedBoolean
| UnaryBooleanOperator BoolExpr
| "(" BoolExpr BinaryBooleanOperator BoolExpr ")"
UnaryBooleanOperator ::= "!"
BinaryBooleanOperator ::= "&&" | "||"
Procedure ::= ProcedureName "(" ARGList ")"
ARGList ::= {ARG {"," ARG}*}?
ARG ::= Bool
| String
| ComputedBoolean
| NonBooleanExpr
ComputedBoolean ::= "(" NonBooleanExpr ComparisonOperator
NonBooleanExpr ")"
ComparisonOperator ::= "=="
| ">"
| ">="
| "<"
| "<="
| "!="
NonBooleanExpr ::= Int
| Float
| Var
| Procedure
| UnaryArithmeticOperator NonBooleanExpr
| "(" NonBooleanExpr BinaryArithmeticOperator
NonBooleanExpr ")"
UnaryArithmeticOperator ::= "-"
BinaryArithmeticOperator ::= "+"
| "-"
| "/"
| "*"
| "%"
| "&"
| "|"
ActionList ::= {Action {";" Action}*}?
A. Taal et al. Expires: September 2004 [Page 8]
Internet Draft Grammar for Policies in Generic AAA March 2004
Action ::= Var "=" Bool
| Var "=" String
| Var "=" ComputedBoolean
| Var "=" NonBooleanExpr
| Procedure
| DrivingPolicy
Var ::= Source {"." Source}*
Source ::= Identifier "::" Identifier "." Identifier
ProcedureName ::= Identifier
Identifier ::= "[a-zA-Z_].[a-zA-Z0-9_]*"
String ::= "\"[^"\n]*\""
Int ::= "-?[0-9]+"
Float ::= "-?[0-9]+\.[0-9]*(E-?[0-9]+)?"
Bool ::= "(true|false)"
A Driving Policy can be viewed as an if-then-else structure.
The Condition (if-part) yields a Boolean value, which may be
the result of evaluating a larger expression. Both the then-
part and the else-part consist of a list of Actions (ActionList).
Actions are tasks to be performed, and their execution is guarded
by the Condition. The Actions in the then-part are executed when
the Condition is true, and the Actions in the else-part are 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. A Driving Policy is said to be
false if and only if the Condition is false. In all other
situations, the state of the Driving Policy is undetermined due to
the occurrence of an error (see section 3.3).
Driving Policies can be nested in ActionLists. A Driving Policy in
an ActionList gives the possibility to express a more deterministic
policy.
The component Procedure can be interpreted as a function call to
an Application Specific Module (ASM), or more general a call to a
generic library function the AAA server is equipped with.
In the next sections we will explain the syntax of the grammar
accompanied with remarks about the semantics of 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, unless
concurrency operators are introduced.
A Condition, or Boolean expression, is composed of four different
types of operands: Bool, Var, Procedure or ComputedBoolean.
The use of a variable (Var), see below, implies that the value
referenced can be interpreted as a Boolean value. The same holds
for the return value of a Procedure when applied as a operand.
A ComputedBoolean is a comparison between a left and right hand
expression.
An example of a Driving Policy for authentication illustrates some
of the concepts dealt with above, as well as the semantics of Var
and Procedure:
if( ASM::Authenticator.checkPassword(
Request::AuthenticationData.UserID,
Request::AuthenticationData.Passwd )
) then (...) else (...)
Herein, the Condition consists of a Procedure, a call to an ASM
with the name Authenticator, which has a public method
checkPassword. Two arguments, both Vars, have to be passed. As
the Vars start with the reserved word 'Request', the RBE knows
that the values referenced are located in the Request. The dot-
structure indicates the sub-tree of the Request. It is assumed
that the Procedure returns a Boolean value.
An alternative, wherein the Condition consists of a Computed
Boolean, may look like:
if( ( Request::AuthenticationData.Passwd ==
ASM::Authenticator.getPassword(
Request::AuthenticationData.UserID )
)
) then (...) else (...)
A. Taal et al. Expires: September 2004 [Page 10]
Internet Draft Grammar for Policies in Generic AAA March 2004
As stated above, the if-statement is said to be deterministic, and
as such there is no need to allow nesting of Driving Policies in a
Condition. Take for instance the following nested Driving Policy:
if( A || Pol )
then( a0 ) else ( a1 )
with Pol: if( B ) then( b0 ) else ( b1 ).
Adopting the C convention this Driving Policy is equivalent to
if( A ) then( a0 )
else ( if( B ) then( b0 ; a0 ) else( b1 ; a1 ) )
3.2.2. Constants and variables
The grammar allows the use of constants and variables, but like
in other scripting languages (e.g. JavaScript) the grammar does not
provide for type checking. Therefore, the use of variables and
constants of different types in the same expression may result in
an error state. For example the multiplication of a string with a
floating point number results in an abortion of the evaluation.
Variables (Vars) refer to a member of an object tree. The
corresponding dot-structure indicates an unique path to a node of
the object tree. We use the following definitions. A node of an
object tree is a leaf if it has no children. All other nodes are
internal nodes. If a Var refers to a leaf of an object tree, it
refers to a primitive type, like an int, float or string value.
A Var refers to an empty object tree if the head of the
corresponding dot-structure does not begin with the reserved word
'Request' or 'Reply', and it is neither the head of a previously
mentioned dot-structure. Such a Var may be interpreted
as a leaf without a value.
A relative simple implementation of a RBE suffices if we restrict
ourselves to Vars representing a leaf of an object tree, i.e. a
primitive value. In case Vars representing an internal node are
desired, Vars refer to objects to be created by the RBE, and some
additional remarks about the semantics of assignments with
variables should be made.
Consider the assignment of the form Var = Var with corresponding
dot-structure A.B.C = D.E.
Four different cases can be distinguished.
1) The left and right hand side both refers to an existent object
tree, i.e. a non-empty object tree. Then the assignment means that
the leaf C obtains the value of leaf E.
2) The left-hand side is an existent object tree whereas the
right-hand side is an empty object tree. This means that C becomes
a leaf with no value.
3) The left-hand side is an empty object tree whereas the
right-hand side is an existent object tree. This is the
declaration of a new 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.
A variable, Var, is a dot-structure and provides the RBE with the
information where the value referenced can be retrieved. The
object tree of the request always starts with the reserved word
'Request', whereas the object tree of the corresponding reply begins
with the reserved word 'Reply'.
Consider the following example of an AAA request in XML:
<Request type="Service" >
<ServiceData>
<SwitchData>
<Source>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>500</Bandwidth>
<StartTime>12:45</StartTime>
<Duration>45</Duration>
</SwitchData>
</ServiceData>
</Request>
A variable 'Request::ServiceData.SwitchData.Bandwidth' indicates a
unique path to the node <Bandwidth>.
3.2.3. Procedures
A Procedure may be interpreted as a function call to an Application
Specific Module (ASM), or as a call to a library function the
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 that case the truth-value of the Procedure
is implicitly used to determine the truth-value of the Condition,
whether or not an assignment is made.
A Procedure is also used to reference to other policies.
Referencing a local policy, stored in the local PR, might be
implemented as a call to a generic function or to an ASM. If a
remote policy is referenced, a policy stored in the PR of another
AAA server, communication with another AAA server during policy
evaluation is needed. A future AAA protocol (section 4) should
provide for request/reply objects in order to support referencing
remote policies. Such a reference might also be implemented as a
call to a generic function or to 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 always exhibit the same behavior, we
propose the following semantics with respect to Actions.
All Actions in an ActionList must always be executed immediately
after evaluating the corresponding Condition. Immediately here
means that Actions are executed in the order in which they appear
in the ActionList, and an Action is only executed when the previous
Action has finished successfully. During execution of the Actions
in the ActionList, policy evaluation is postponed.
The introduction of concurrency operators in the grammar may open
the possibility to indicate in which order Actions should 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
Procedure, for example getPassword(..), might fail to respond
because the database is off-line. Since we allow arithmetic
expressions, another type of error might be caused by a
division by zero. As Vars might be of different types,
incompatibilities might occur during evaluation of an expression,
like a string multiplied by a float. Because the grammar does not
provide for exception handling, the most safe strategy is to abort
the evaluation of the policy after error occurrence. Error codes
might be defined to inform the requester about the abortion of its
request. In any case it is necessary to define a special Reply to
inform the requester that policy evaluation has aborted.
There are several possibilities to reduce the occurrence of
errors. With respect to the failure of Procedures, the
administrator can make sure that the Driving Policies are
constructed in such a way that the occurrence of error states are
limited. This might be done by checking the input for Procedures
if it meets the precondition. Take for instance a Service request
for bandwidth that contains an object ServiceData. A precondition
for the call to the appropriate ASM, might be that the requested
bandwidth is at least 10 and at most 1000. Then a Driving Policy
may look like:
if( (Request::ServiceData.SwitchData.Bandwidth >= 10) )
then
(
if( ( Request::ServiceData. SwitchData.Bandwidth <= 1000 ) )
then(...)
else( Reply::Answer.Message = "Bandwidth too large" )
)
else( Reply::Answer.Message = "Bandwidth too small" )
A. Taal et al. Expires: September 2004 [Page 13]
Internet Draft Grammar for Policies in Generic AAA March 2004
If AAA requests are defined by XML, XML Schema's or DTDs might be
used. An XML schema provides a means for defining the structure,
content and the semantics of an XML document. This eliminates
errors due to the bad contents of a request.
The RBE might check division or incompatibilities in arithmetic
expressions, as well as terminate policy evaluation after time out
of a function call.
4. Data Objects and Message Types
This section describes the need for a specification of the message
types and the top level objects to be carried in a future AAA
protocol. As the number of different AAA servers is almost
unlimited, the same holds for the number of different
Request/Reply pairs. An AAA server providing bandwidth has little
in common with an AAA server for the ordering of a pizza.
A new technique like WSDL (Web Services Description Language) opens
the possibility to cope with the expected diversity in AAA
Request/Reply pairs. WDSL [WSDL] can be used to specify in detail
information about the service an AAA server delivers such as the
type of data it requires (Request) and the type of data it produces
(Reply). Applying WSDL, the specification of the message types and
the top level objects can be limited to those messages needed for
the intercommunication between AAA servers.
Such a list of message types should 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, and
a ServiceData object. The correspinding Driving Policy asks for
the authentication of the requester before the service will be
delivered
A. Taal et al. Expires: September 2004 [Page 14]
Internet Draft Grammar for Policies in Generic AAA March 2004
The Request:
<?xml version="1.0" encoding="UTF-8"?>
<Request version="0.1" type="Service" >
<AuthenticationData>
<Identity>Joe</Identity>
<Password>aaa</Password>
</AuthenticationData>
<ServiceData>
<SwitchData>
<Source>192.168.1.5</Source>
<Destination>192.168.1.6</Destination>
<Bandwidth>500</Bandwidth>
<StartTime>12:45</StartTime>
<Duration>45</Duration>
</SwitchData>
</ServiceData>
</Request>
The corresponding Reply:
<?xml version="1.0" encoding="UTF-8"?>
<Reply version="0.1" type="Service" >
<Answer><Message></Message></Answer>
</Reply>
The AAA server recognizes the request as an Service request and
draws the corresponding Driving Policy from the PR:
if
( ASM::Authenticator.Authenticate(
Request::AuthenticationData.Identity,
Request::AuthenticationData.Password )
)
then
( if
( ASM::RM.CheckConnection(
Request::ServiceData.SwitchData.Source,
Request::ServiceData.SwitchData.Destination )
)
then
( if
( (Request::ServiceData.SwitchData.Bandwidth <= 1000 )
)
then
(
R1 = ASM::RM.BoD(
Request::ServiceData.SwitchData.Source,
Request::ServiceData.SwitchData.Destination,
Request::ServiceData.SwitchData.Bandwidth,
Request::ServiceData.SwitchData.StartTime,
Request::ServiceData.SwitchData.Duration )
A. Taal et al. Expires: September 2004 [Page 15]
Internet Draft Grammar for Policies in Generic AAA March 2004
;
if( ( R1 < 0 ) )
then
( Reply::Answer.Message = "UNKNOWN failure occurred"
)
else
( Reply::Answer.Message = "Request successful"
)
)
else
( Reply::Answer.Message = "Bandwidth too small"
)
)
else
( Reply::Answer.Message = "Bad source or destination"
)
)
else
( Reply::Answer.Message = "Authentication failed"
)
An Action like, Reply::Answer.Message = "Authentication failed",
instructs the RBE to add a text node to the Reply that is returned
to the User.
6. Other policy languages
The language according to the presented grammar describes policies
that might be implemented in several policy languages. However the
concept of a Driving Policy presented in this paper (fig. 2)
justifies the definition of a special restricted grammar for
Driving Policies. The concept chosen allows for a policy
language with as few predefined terms as possible as the tasks an
AAA server has to perform are mainly delegated to Application
Specific Modules or generic AAA functions.
References
[RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Voll-
brecht, "Generic AAA Architecture", RFC 2903, August 2000
[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 2004 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-22 04:25:28 |