One document matched: draft-irtf-aaaarch-generic-policy-06.txt
Differences from draft-irtf-aaaarch-generic-policy-05.txt
AAAARCH Research Group A. Taal
INTERNET DRAFT G. Sliepen
Category: Informational C.T.A.M. de Laat
September 2004
A grammar for Policies in a Generic AAA Environment
<draft-irtf-aaaarch-generic-policy-06.txt>
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
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
documents 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.
A. Taal et al. Expires: March 2005 [Page 1]
Internet Draft Grammar for Policies in Generic AAA September 2004
Abstract
In this document the concept of a so-called Driving Policy is
presented. 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Other policy languages . . . . . . . . . . . . . . . . . . . 17
References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 17
A. Taal et al. Expires: March 2005 [Page 2]
Internet Draft Grammar for Policies in Generic AAA September 2004
1. Introduction
Before discussing the role of a Driving Policy and how it fits into
the AAA concept, an abstract view of a generic AAA environment
[RFC2903] is presented in fig. 1. Only those components are
presented that are necessary to support the discussion in this
draft.
+----+ +---+ +---+
|User|<======>|AAA|<===================================>|AAA|
+----+ +---+<========= =========>+---+
/\ /\ \\ // /\ /\
|| || || || || ||
|| \/ || || || \/
\/ +--+ || || \/ +--+
+---+ |PR| || || +---+ |PR|
|ASM| +--+ \/ \/ |ASM| +--+
+---+ +---+ +---+ +---+
|AAA|<=========>|AAA|
+---+ +---+
/\ /\ /\ /\
|| || || ||
|| \/ || \/
\/ +--+ \/ +--+
+---+ |PR| +---+ |PR|
|ASM| +--+ |ASM| +--+
+---+ +---+
Figure 1. The abstract view of a generic AAA environment
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: March 2005 [Page 3]
Internet Draft Grammar for Policies in Generic AAA September 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: March 2005 [Page 4]
Internet Draft Grammar for Policies in Generic AAA September 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
relationships 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
corresponding 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: March 2005 [Page 5]
Internet Draft Grammar for Policies in Generic AAA September 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 RBE 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
necessary 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: March 2005 [Page 6]
Internet Draft Grammar for Policies in Generic AAA September 2004
2.6. The Use Case 'Perform Accounting'
Accounting is the collection of all the data about resource
consumption. 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.
The Use Cases 2.4, 2.5 and 2.6 concerning authentication,
authorization and accounting are complex Use Cases in the sense that
special ASMs are involved rather than generic AAA functions. In
general these special ASMs will apply their own policies (language).
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: March 2005 [Page 7]
Internet Draft Grammar for Policies in Generic AAA September 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: March 2005 [Page 8]
Internet Draft Grammar for Policies in Generic AAA September 2004
Action ::= Var "=" Bool
| Var "=" String
| Var "=" ComputedBoolean
| Var "=" NonBooleanExpr
| Procedure
| DrivingPolicy
Var ::= {Source "::" }? Source {"." Source}*
Source ::= Identifier
ProcedureName ::= Identifier "::" Identifier "." 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
executed 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: March 2005 [Page 9]
Internet Draft Grammar for Policies in Generic AAA September 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 '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: March 2005 [Page 10]
Internet Draft Grammar for Policies in Generic AAA September 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 "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: March 2005 [Page 11]
Internet Draft Grammar for Policies in Generic AAA September 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 or stored.
The object tree of the request always starts with 'Request::',
whereas the object tree of the corresponding reply begins
with '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>.
The following assignments are syntactically correct:
Request::AuthenticationData.UserID = "John"
ABC::Count = Reply::Answer.Value
but it is not clear what the semantic meaning is. It depends on
the implementation of the RBE. The first assignment might be
implemented such that the request variable is changed and
subsequent use of the same variable will apply the modified value,
or the RBE might raise an error in case request variables are
interpreted as read-only variables. The second assignment might
fail in case the reply variable has not been assigned a value in a
previous action, or in case the RBE interprets reply variables as
write-only variables.
3.2.3. Procedures
A Procedure may be interpreted as a function call to an Application
Specific Module (procedure name starts with "ASM::"), or as a call
to a library function the Generic AAA server is equipped with
A. Taal et al. Expires: March 2005 [Page 12]
Internet Draft Grammar for Policies in Generic AAA September 2004
(procedure name starts with "AAA::"). If an assignment is made the
return value is accessible in the remaining policy. From section
3.2.2 it follows that the return value is a primitive value, like
an int, float or string. 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.
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.
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
within a specified time 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. The
detection of erroneous situations, including timeout of ASM calls,
A. Taal et al. Expires: March 2005 [Page 13]
Internet Draft Grammar for Policies in Generic AAA September 2004
is the responsibility of the RBE. In general the AAA server should
be notified too about errors, as the AAA server supervises all
activities.
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" )
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. Taal et al. Expires: March 2005 [Page 14]
Internet Draft Grammar for Policies in Generic AAA September 2004
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
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:
A. Taal et al. Expires: March 2005 [Page 15]
Internet Draft Grammar for Policies in Generic AAA September 2004
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 )
;
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.
A. Taal et al. Expires: March 2005 [Page 16]
Internet Draft Grammar for Policies in Generic AAA September 2004
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
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: March 2005 [Page 17]
Internet Draft Grammar for Policies in Generic AAA September 2004
Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
A. Taal et al. Expires: March 2005 [Page 18]| PAFTECH AB 2003-2026 | 2026-04-22 04:25:27 |