AAAARCH Research Group INTERNET DRAFT Category: Experimental S.M.C.M. van Oudenaarde L.H.M. Gommans C.T.A.M. de Laat F. Dijkstra A. Taal September 2004 Prototype of a Generic AAA Server draft-irtf-aaaarch-prototype-02.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. Oudenaarde et al. Expires: March 2005 [Page 1] Experimental RFC Prototype of a Generic AAA Server September 2004 Abstract In this document a prototype of an AAA (Authentication, Authorization, Accounting) server is presented. The prototype is build in accordance with the RFCs 2903, 2904 and 2905. As the AAA concept is a multi-tier concept we have chosen for JAVA Enterprise Beans (J2EE) to build the prototype. New techniques and protocols supported by the J2EE platform are discussed. Web service standards like SOAP are explored. A general architecture of an AAA server is outlined in Enterprise JavaBeans (EJB) component architecture. Table of Contents Status of this Memo . . . . . . . . . . . . . . . . . . . . . 1 Copyright Notice . . . . . . . . . . . . . . . . . . . . . . 1 Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3 2. Generic AAA Architecture . . . . . . . . . . . . . . . . . 3 2.1 Agent, pull and push sequences . . . . . . . . . . . . . 4 2.1.1 The agent sequence . . . . . . . . . . . . . . . . . . 4 2.1.2 The 'push' and 'pull' sequence . . . . . . . . . . . 5 3. The demo setup . . . . . . . . . . . . . . . . . . . . . . 5 4. Implementation details . . . . . . . . . . . . . . . . . . 6 4.1 AAA Requests in the Generic AAA Architecture . . . . . . 6 4.2 Interface(s) . . . . . . . . . . . . . . . . . . . . . . 8 4.3 Driving Policy . . . . . . . . . . . . . . . . . . . . . 9 4.4 ASM Framework . . . . . . . . . . . . . . . . . . . . . 10 4.5 Session . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Conclusions and suggestions for further research . . . . 11 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix B . . . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Oudenaarde et al. Expires: March 2005 [Page 2] Experimental RFC Prototype of a Generic AAA Server September 2004 1. Introduction The RFCs 2903, 2904 and 2905 describe the concept of AAA, Authentication, Authorization and Accounting. These RFCs were a product of the AAAARCH research group of the IRTF. As members of this research group we present a prototype of an AAA server in accordance with these RFCs. We have chosen for the J2EE platform that offers a multitiered distributed application model. The J2EE environment offers support for Extensible Markup Language (XML)- based data interchange, flexible transaction control, an unified security model, and Web services that are based on SOAP and HTTP. Several key parts of the AAA concept, not specified in the above mentioned RFCs, are introduced. One newly introduced key part is a so called AAA Driving Policy. For each request an AAA server understands there exists a corresponding Driving Policy that is evaluated. 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. AAA requests are expressed in XML whereas Driving Polices are expressed in a special policy language (see Appendix A). AAA servers will be specialized in delivering certain kind of services. Support for WSDL, an XML format for describing network or web services, and support for UDDI, a meta service for discovering network or web services, are integrated into the AAA concept. These techniques give clients the possibility to discover to which AAA server they should address what kind of request in order to get the service of their desire delivered. Part of the J2EE platform is the Enterprise JavaBeans (EJB) standard. This is a component architecture for deployable server-side components in Java. The generic AAA server is build of EJB components, Session Beans and Entity Beans. 2. Generic AAA Architecture Before discussing implementation details we will outline an abstract view of the Generic AAA Architecture. The Generic AAA Architecture comprises of four major components, fig. 1. An AAA Request is any kind of message that asks for a service. When a Generic AAA Server receives an AAA Request it will initiate the evaluation of a policy, a so-called Driving Policy. This Driving Policy instructs the Generic AAA Server what conditions need to be checked before certain Service Equipment is told to do something. Service Equipment can be anything, like switches, routers, bandwidth brokers, network access equipment, remote instrumentation, etc. The ASM, Application Specific Module, forms an API to communicate with the Service Equipment. So an Application Specific Module is a component of an AAA Server that allows Driving Policies to influence Service Equipment. There exists a tight relationship between AAA Requests, Driving Policies, and Application Specific Modules. Firstly, AAA Requests and Driving Policies have a one-to-one and onto relationship. Oudenaarde et al. Expires: March 2005 [Page 3] Experimental RFC Prototype of a Generic AAA Server September 2004 +-------------+ |+-------------+ +| AAA Request | +-------------+ /\ / \ / \ / \ / \ / Generic \ / AAA \ /--------------\ +----------------+ +-------+ |+----------------+ |+-------+ +| Driving Policy | +| ASM | +----------------+ +-------+ Fig. 1 Components of the Generic AAA Architecture Based on the request type, the AAA server to retrieve the Driving Policy that needs evaluation. All actions in a Driving Policy refer either to a generic function the Generic AAA is equipped with or to an Application Specific Module. 2.1 Agent, pull and push sequences In RFC 2904 "AAA Authorization Framework" three authorization sequences are described, the 'agent', the 'pull', and the 'push' sequence. In the following we focus on the Îagentâ model. 2.1.1 The agent sequence In the agent sequence (fig. 2), the AAA Server functions as an agent between the User and the Service Equipment (SE). The User sends a Request to the AAA Server (1). The Interface unpacks the Request and sends it to a Rule Based Engine (RBE) (2). Before the RBE will retrieve the corresponding Driving Policy and Reply from the Policy Repository (PR) (4), it asks for a new Session to be created (3). Instructed by the Driving Policy the RBE calls one or more ASMs (5) and passes the arguments needed. While an AAA server has exactly one RBE defined, and one Session Manager, it may have multiple ASMs at its disposal. Arguments passed to an ASM may originate from the incoming request or from values returned by previous calls. These arguments might be needed by the Service Equipment the ASM interfaces to (6). Values returned by an ASM (7) may also be inserted into the Reply to the User. Once the Driving Policy has been decided the Reply is returned to the User (8,9). When there is no need for the Session Manager to keep the information of this Session into persistent storage after Oudenaarde et al. Expires: March 2005 [Page 4] Experimental RFC Prototype of a Generic AAA Server September 2004 the User received an answer, the Session Manager might write that information into a log file. .............................................. : : +------+ : +-----------+ AAA : | |---1---->| | : | User | : | Interface | : | |<--9-----| | : +------+ : +-----------+ +-------- + : : ^ | | Session | : : | | ->| Manager | : : 8 2 / +---------+ : : | v 3 : : +------+ / : : | |<--/ +------+ : : | RBE |----5---->| ASM |+ : : | |<---7-----| || : : +------+ +------+| : : ^ +^----+ : : 4 | 6 | : :.........|................|.................: v v +-----+ +-----+ | PR | | SE | +-----+ +-----+ Fig. 2 Schematic view of an agent sequence. 2.1.2 The 'push' and 'pull' sequence In the 'pull' sequence, as defined in [RFC 2904], the User sends a service request to the Service Equipment, which forwards it to an AAA Server. The AAA Server evaluates the request and returns an appropriate response to the Service Equipment, which sets up the service and tells the User it is ready. Here the Service Equipment sends an AAA Request to the AAA Server. In general the the User and Service Equipment apply a different protocol, and the Service Equipment has to translate the request from the User and the Reply from the AAA Server. In the 'push' sequence it is the User that in general applies two different protocols. There the User gets from an AAA Server a ticket or certificate verifying that it is o.k. for the User to have access to a Service Equipment. 3. The demo setup The AAA server build of EJB components and discussed below is applied in the following setup (fig. 3). We setup a QoS (Quality of Service) path provision demo between two administrative domains. Oudenaarde et al. Expires: March 2005 [Page 5] Experimental RFC Prototype of a Generic AAA Server September 2004 In each administrative domain an AAA server (2 and 3) takes care of the admission control of the network elements needed for the QoS path. The network elements, Calient Optical Cross Connects (OXC), were interconnected by two optical links (lambda 1 and 2). One domain, called NetherLight, was situated at the Dutch optical research facility. The other domain, called StarLight, was at the USA Chicago-based counterpart. In fig. 3 the AAA server 1 acts as a broker that tries to find the resources, i.e. the AAA servers 2 and 3 needed to setup the QoS path. The authorization decision is a multi-domain decision. Both 'admission-AAAs' (2 and 3) will make local decisions that are used in an overall authorization decision by the 'broker-AAA' (1). All three AAA servers have in their own Driving Policy. The Driving Policies applied by the 'admission-AAAs' refer for complex tasks, like configuration checks on the state of the OXCs, to their own ASMs. These ASMs are hiding the complexity of the tasked to be performed for the setup of the QoS path. If a User's request is satisfied, a dedicated optical path is provisioned, which could be used for large traffic between the two domains. +-----+ +-----+ | OXC |------------lambda 1 -------------| OXC | | | | | | |----------- lambda 2 ------------ | | +-----+ +-----+ | | | | +-----+ +-----+ | AAA | | AAA | | 2 | | 3 | +-----+ +-----+ | | \ / \ +-----+ / \----------------| AAA |-------------/ | 1 | +-----+ | () | -()- ------/ /\ User Fig. 3 Demo setup for QoS path provision. 4. Implementation details 4.1 AAA Requests in the Generic AAA Architecture An AAA Request defines what can be asked of or provided to a Generic AAA Server. For each kind of AAA Request data objects Oudenaarde et al. Expires: March 2005 [Page 6] Experimental RFC Prototype of a Generic AAA Server September 2004 should be defined with the information that can be incorporated into a specific AAA Request. To accommodate all possible future services by a limited number of predefined AAA Requests is undoable. There is only a need to predefine AAA Requests for the inter communication among AAA Servers, e.g. a request for remote authorization or policy evaluation. Web services standards such as SOAP, WSDL and UDDI will enable the creation of AAA Server specific Requests and data objects contained, e.g. how construct an AAA Request to order a pizza at a pizza AAA Server. The WSDL (Web Services Description Language) is an XML-based document that defines the inputs and outputs of a Web Service, including the XML Schemas that should be used to create the input and output documents. Using WSDL, AAA Request/Reply pairs might be described for special Web Services. Fig 4 shows a logical view of the Web services architecture. The Service Registry provides a centralized location for storing service descriptions. An UDDI registry is an example of this type of service registry. +------------------+ =======>| Service Registry |<======= || +------------------+ || Find || || Publish || || \/ \/ +-------------------+ Bind +------------------+ | Service Requestor |<==========>| Service Provider | +-------------------+ +------------------+ Fig. 4 In our setup the User sends its (XML) Request in the body of a SOAP message over HTTP. A simple Bandwidth on Demand (BoD) Request the 'broker-AAA' accepts, might look like: 17520 Joe 7531 hp2 BeautyCees Oudenaarde et al. Expires: March 2005 [Page 7] Experimental RFC Prototype of a Generic AAA Server September 2004 NetherLight 2 scyalla5 CHI StarLight 2 1000 now 20 The 'type' attribute of the first XML-tag, 'LambdaBoDCross' indicates the kind of Request and is used by the Rule Base Engine to retrieve the corresponding Driving Policy from the repository. Also, this version of the policy is limited to two domains. A typical policy would incorporate usage of a route discovery ASM. 4.2. Interface(s) We use a servlet, a web-tier component, as a facade for making the AAA functionality available to the outside world. There are a couple of advantages for this approach. As the AAA functionality is based on EJB-technology, both the Client tier and the EJB tier implementation are independent. Clients may access EJB components through a RMI-IIOP connection, but that excludes clients behind a firewall. This fact also favors the choice for a servlet as a single point of access, as firewalls are transparent for HTTP. Additionally an EJB component has to expose its remote interface in order to communicate with the outside world. This means that every single call of the client on an EJB component initiates a remote (RPC) call over the network. For each invocation the EJB Server checks security, transactionality, etc. This might lay a heavy load on the EJB Server in case several methods on several EJB components need to be called by the client in order to get a service done. All these problems are circumvent by a servlet as a single point of entry using the local interface of a session bean (EJB2.0). The session bean the servlet interfaces to is the RBE that will contact those EJB components needed for the service requested. Which EJB components are needed are described by a Driving Policy. Only some simple actions are performed by the servlet. It extracts the Request from the body of the SOAP message and checks the schema attributes. It are these attributes the parser of the RBE will apply and they should be correct. Oudenaarde et al. Expires: March 2005 [Page 8] Experimental RFC Prototype of a Generic AAA Server September 2004 4.3 Driving Policy In the policy language designed and applied, a Driving Policy is of the form 'if( Condition ) then ( ActionList ) else ( ActionList )'. For the grammar see Appendix A. An 'if-then-else' structure has a Boolean truth-value, it is 'true' if its Condition is 'true', and it is 'false' if its Condition is 'false'. To facilitate the discussion we present a simple Driving Policy in chunks (this is not supported by the grammar). A simple Driving Policy for an AAA server that accepts the above Service request looks like: if( ASM::Authenticator.CheckSignature( Request::Authentication.Signature, Request::Authentication.User ) ) then( ACTION_LIST_1 ) else( Reply::Error.Message = "Authorization failed" ) The authentication is delegated to an ASM called Authenticator. Two arguments from the incoming Request are passed to a member function 'CheckSignature' of the authenticator. When the authentication succeeds the action list ' ACTION_LIST_1' in the then-part is executed, otherwise an error message is returned. Action list 'ACTION_LIST_1' consists of two actions, a call to an ASM and an if-then-else structure: credential = ASM::Authorizor.CheckCredentials( Request::Authorization.credentialID ) ; if( ASM::RM.CheckMultiDomain( Request::BoDData.Source.OXCDomain, Request::BoDData.Destination.OXCDomain ) ) then( ACTION_LIST_2_1 ) else( ACTION_LIST_2_2 ) The return state of the 'CheckCredentials' call is assigned to a policy variable 'credential' for later use. Next an resource manager (RM) is asked whether the connection requested is a muti-domain connection or just a single domain set-up. In case a multi-domain set-up is required action list 'ACTION_LIST_2_1' is executed. We confined the discussion to the multi-domain set-up. Action list ACTION_LIST_2_1 has the form: lambda = ASM::RM.Connection( Request::BoDData.Source.OXCDomain, Request::BoDData.Destination.OXCDomain ) ; Oudenaarde et al. Expires: March 2005 [Page 9] Experimental RFC Prototype of a Generic AAA Server September 2004 if( (lambda <= 0) ) then( Reply::Error.Message = "No connection available between domains" ) else( ACTION_LIST_3 ) The connection between the two domains is a virtual lambda and further actions are needed to resolve this virtual connection [FGCS]. In action list 'ACTION_LIST_3' the requested connection is provisioned: r1 = ASM::AAABean.Cross( credential, Request::BoDData.Source.OXCDomain, lambda, Request::BoDData.Source.OXCPort, Request::BoDData.Bandwidth, Request::BoDData.StartTime, Request::BoDData.Duration ) ; if( (r1 <= 0) ) then( Reply::Error.Message = "failed to make cross-connect to port in SRC domain" ) else( ACTION_LIST_4 ) Here the call 'Cross' results in an AAA Request to the AAA Server of the source domain, in fig. 3 this is AAA Server 2. Action list 'ACTION_LIST_4' is similar to 'ACTION_LIST_3': r2 = ASM::AAABean.Cross( credential, Request::BoDData.Destination.OXCDomain, lambda, Request::BoDData.Destination.OXCPort, Request::BoDData.Bandwidth, Request::BoDData.StartTime, Request::BoDData.Duration ) ; etc. We short cut the discussion with the remark that in case the call to the destination AAA Server fails (AAA Server 3 in fig. 3) an additional call to the source AAA Server has to be made to cancel the provisioning. For details about the implementation of Driving Policies as Java objects see Appendix B. 4.4 ASM Framework Application Specific Modules extend the J2EE environment to the outside world. For example in our Bandwidth on Demand (BoD) service an ASM monitors and controls the state of switches. This is realized with the Java Connector Architecture (JCA). The JCA is the bridge between J2EE and the Enterprise Information Systems. Oudenaarde et al. Expires: March 2005 [Page 10] Experimental RFC Prototype of a Generic AAA Server September 2004 JCA standard provides a mechanism to store and retrieve enterprise data in J2EE. To make a decision in the RBE about a BoD service the state of a switch needs to be checked. This is realized by a connection oriented control adapter (JCA), which translates the current state of the switch to an EJB entity bean in the J2EE container. All information of the switch(es) are translated into the entity bean, including the methods to control the switch. 4.5 Session If an incoming Request is forwarded to the RBE, a Session Manager (entity bean) is contacted by the RBE. The Session Manager starts a session that will keep information about the Use Case of the AAA Request. Each session is characterized by a sessionID, in our case a primary key. The session information itself is persistent, as the information must be recoverable after failure of the AAA server. There are Use Cases for which the session information should be kept in persistent storage for a certain time span after the User received a Reply. In order to inform the RBE whether or not it should ask for a Session persistent after the Reply is returned, a special attribute in the Request tag might be defined. In case the Session information should be kept for a longer time, the Driving Policy has at least one Action to add the sessionID to the Reply returned. This sessionID is needed to retrieve information about or add information to the Session. For auditing or accounting purposes full information of all equipment involved should be available at the AAA server that received the Request. This description of an AAA Session is far from complete and further research is needed to complete it (see next section). 5. Conclusions and suggestions for further research The Generic AAA architecture is best suited for policy based decision taking at the business level involving high level service abstractions and user definitions. The business level involves decision taking based on simple policy rules and simple messages exchanged. Due to the diversity in service operation methods, a flexible way is needed to interface with various service entities in different domains. The role assigned to Driving Policies in the AAA concept and the relatively simple policy language suffice to make the decision taking at the business level. Fine-grained policy decisions should not be made at the level of Driving Policies, but should be made by ASMs applying proprietary admission control software. The policy language forces the developer to off-load all semantic handling of attributes not important at the business level to ASMs. This entails that multi- domain decision taking is purely made on business logic. Further research is needed to prove the correctness and usefulness of this approach. Another issue to be settled by further research is performance. To set-up a QoS path involves decision taking at Oudenaarde et al. Expires: March 2005 [Page 11] Experimental RFC Prototype of a Generic AAA Server September 2004 different levels and in different domains and might be a time consuming process. One way to cope with long set-up times is parallelization. The policy language should allow the use of concurrency operators. A consequence of concurrent actions is the need to cancel actions in process in case the failure of one action makes the outcome of other ongoing, unfinished actions irrelevant. Other questions we are interested in is how a dynamic trust-relation with other parties can be established and how to combine authorizations from different administrative domains applying pre-established trust relationships. Authorizations based on monetary units seem a promising approach. Inter AAA communication might be based on a TLS based transport mechanism or on an RFC3281 attribute certificate in a the Request. Integration of Security Assertion Markup Language (SAML) in the above AAA concept is worthwhile to look at. Finally, some standardization of messages is required, especially for those messages exchanged among AAA Servers, e.g. to retrieve a policy from another AAA Server or error message including error codes. Appendix A A grammar for Driving 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 ::= Bool | Var | {Var "="}? Procedure | ComputedBoolean | UnaryBooleanOperator Condition | "(" Condition BinaryBooleanOperator Condition ")" UnaryBooleanOperator ::= "!" BinaryBooleanOperator ::= "&&" | "||" Procedure ::= ProcedureName "(" ARGList ")" ARGList ::= {ARG {"," ARG}*}? ARG ::= Bool | String | ComputedBoolean | NonBooleanExpr ComputedBoolean ::= "(" NonBooleanExp ComparisonOperator NonBooleanExpr ")" Oudenaarde et al. Expires: March 2005 [Page 12] Experimental RFC Prototype of a Generic AAA Server September 2004 ComparisonOperator ::= "==" | ">" | ">=" | "<" | "<=" | "!=" NonBooleanExpr ::= Int | Float | Var | Procedure | UnaryArithmeticOperator NonBooleanExpr | "(" NonBooleanExpr BinaryArithmeticOperator NonBooleanExpr ")" UnaryArithmeticOperator ::= "-" BinaryArithmeticOperator ::= "+" | "-" | "/" | "*" | "%" | "&" | "|" ActionList ::= {Action {";" Action}*}? 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)" Evaluation of a Boolean expression is performed according to the C-language convention. This makes an if-statement 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 ) ) Appendix B A parser for the grammar in Appendix A is discussed by applying Java Compiler Compiler (JavaCC). The semantic actions of the parser yield a Driving Policy as a serialized object. Oudenaarde et al. Expires: March 2005 [Page 13] Experimental RFC Prototype of a Generic AAA Server September 2004 Implementing Driving Policies as a serialized objects, as discussed below, simplifies the RBE to a 'RPN calculator-like' device. This is accomplished by defining some simple classes that cover the non-terminals of the grammar: public class DrivingPolicy { public Stack conditionStack; public Stack thenStack; public Stack elseStack; } public class Procedure extends Stack { public String name = ""; } public class Expression extends Stack { public static final int COMP_BOOLEAN =0; public static final int NON_BOOLEAN =1; public int type = -1; } public class Literal { public static final int BOOL =0; public static final int INT =1; public static final int FLOAT =2; public static final int STRING =3; public static final int VAR =4; public int type = -1; public String stringValue = ""; } public class Operator { public static final int NOT =0; // '!' public static final int AND =1; (...) public static final int GET =6; // '>=' (...) public static final int PLUS =9; // '+' public static final int MINUS =10; public static final int MUL =11; // '*' (...) public int type = -1; } public class Assignment { public Object lval; public Object rval; } The following example will illustrate how the parser produces a Driving Policy object. Take for example the following Driving Policy that checks whether some arithmetic manipulation of a Oudenaarde et al. Expires: March 2005 [Page 14] Experimental RFC Prototype of a Generic AAA Server September 2004 number 'Data' from a request is larger than the number 169: if( ( ASM::Calculator.power(((2*3)+Request::Data),2) >= 169 ) ) then( Reply::Answer = "Yes" ) else( Reply::Answer = "No" ) The serialized JAVA object produced has three stacks that are populated as follows: conditionStack: | - Procedure(ASM::Calculator.power): | | - Expression(NON_BOOLEAN): | | | - Literal(INT): "2" | | | - Literal(INT): "3" | | | - Operator(MUL) | | | - Literal(VAR): "Request::Data" | | | - Operator(PLUS) | | | | - Expression(NON_BOOLEAN): | | - Literal(INT): "2" | | - Literal(INT): "169" | - Operator(GET) thenStack: | - Assignment: | - lval: | | -Literal(VAR): Reply::Answer | | - rval: | - Literal(STRING): "Yes" elseStack: | - Assignment: | - lval: | | -Literal(VAR): Reply::Answer | | - rval: | - Literal(STRING): "No" The 'conditionStack' contains three objects, a Procedure object, a Literal object, and an Operator object. All objects are placed on the 'conditionStack' adhering to Reverse Polish Notation (RPN). This also holds for the stack of an Expression object. This simplifies the RBE to a 'RPN calculator' like device in determining the truth- value of the Condition. It just pops, resolves and pushes objects from and onto the 'conditionStack' until the stack contains a single Literal object of the type BOOL. Oudenaarde et al. Expires: March 2005 [Page 15] Experimental RFC Prototype of a Generic AAA Server September 2004 Depending on the 'stringValue', whether it is 'true' or 'false', the RBE continues with the 'thenStack' or the 'elseStack' of the DrivingPolicy object. References [FGCS] Leon Gommans, Cees de Laat, Bas van Oudenaarde, Arie Taal "Authorization of a QoS path based on generic AAA" in Future Generation Computer Systems, pp. 1009-1016. Authors' Addresses Bas van Oudenaarde Faculty of Science, Informatics Institute, University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257586 Fax: +31 20 5257490 Email: oudenaar@science.uva.nl Leon Gommans Faculty of Science, Informatics Institute, University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257435 Fax: +31 20 5257490 Email: lgommans@science.uva.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 Oudenaarde et al. Expires: March 2005 [Page 16] Experimental RFC Prototype of a Generic AAA Server September 2004 Freek Dijkstra Faculty of Science, Informatics Institute, University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257531 Fax: +31 20 5257490 Email: fdijkstr@science.uva.nl Arie Taal Faculty of Science, Informatics Institute, University of Amsterdam Kruislaan 403 1098 SJ Amsterdam The Netherlands Phone: +31 20 5257586 Fax: +31 20 5257490 Email: taal@science.uva.nl 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. Oudenaarde et al. Expires: March 2005 [Page 17] Experimental RFC Prototype of a Generic AAA Server September 2004 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. Oudenaarde et al. Expires: March 2005 [Page 18]