INTERNET DRAFT J. Salowey draft-irtf-aaaarch-aaa-pol-01.txt G. Sliepen A. Taal D. Spence March 2001 Policies in AAA 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 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. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This document defines some terms related to the Generic AAA architecture. The first section describes some broad aspects of such an architecture. The second section looks at the various aspects and types of policy that come into play in an AAA architecture. The third section will describe some of the components of a single policy. This work is preliminary and is expected to be complimented by other work from the AAAARCH research group such as [POLICY MODEL] and [POLICY ACCOUNTING]. This document is also meant as an extension to the [POLICY] document from the Policy Framework working group. Some terms from the [POLICY] document are also defined in this document, to make it more J. Salowey et al. Expires: September 2001 [Page 1]
Internet Draft Policies in AAA March 2001 self-contained. Where possible, the meaning of the terms has been kept the same. Please note however that the primary focus of this document is the AAAARCH research group, and hence some descriptions may deviate from those given in the [POLICY] document. Comments on this document should be sent to the mailing list of the IRTF AAA architecture [AAAARCH] mailing list: aaaarch@fokus.gmd.de. 1. Generic descriptions 1.1 The Generic AAA Architecture The goal of the Generic AAA Architecture is to control and provide authentication, authorization and accounting for systems and environments based on the policies set by the administrators and users of the system. Much of this section is based on [RFC2903]. The following terms specify some of the broader aspects of the generic AAA architecture: o AAA Domain A single administrative domain. Contains a collection of one or more AAA services owned by the same organizational entity. Note that every AAA Service belongs to one AAA domain, but an AAA domain can contain many AAA Services. Note that this is slightly different from a "policy domain" as defined in [POLICY]. o AAA Server / AAA Service A Service that performs one or more of the following functions: accounting, authentication and authorization. An AAA Server is contained within a single device and is not spread across multiple servers. An AAA Server such as a RADIUS server is an example of an AAA service. The definition of an AAA Service is broader than that of an AAA Server, for example it also includes Service Equipment that authorizes use based on evaluating various Policies. o Application Specific Module (ASM) A component of an AAA Service that allows Policies to influence Service Equipment. Service Equipment can be anything, and therefore there is no standard API to communicate with. An ASM however does have a standard API, and it can be used to translate requests into something the Service Equipment understands. J. Salowey et al. Expires: September 2001 [Page 2]
Internet Draft Policies in AAA March 2001 o Policy As defined in [POLICY]: 1. A definite goal, course or method of action to guide and determine present and future decisions. "Policies" are implemented or executed within a particular context (such as policies defined within a business unit). 2. Policies as a set of rules to administer, manage, and control access to network resources. In the Generic AAA Architecture, Policies are expressed as policy rules. A "simple" policy rule consists of a policy condition and a policy action. The policy condition is evaluated and depending on the evaluation of the condition a policy action is taken or not. A RBE will evaluate the policy condition to take a policy decision. Based on the outcome, the RBE will execute the policy action. o Request A Request is any kind of message that asks for a service. There are lots of different requests (see [OBJMSG]), and many ways to send a request to the service, for example via the push, pull or agent model as described in [RFC2904]. A Request will initiate the evaluation of one or more Policies, which may execute some Actions and return a response. o Rule Based Engine (RBE) A RBE may be generic and able to process rules of a given type with little or no knowledge of an application. In other cases the RBE may be application specific. In general, a RBE in service equipment is application specific. A generic RBE may enlist the help of an Application Specific Module (ASM) to evaluate some policies. A policy decision may result in either a true or false, which may then result in an action that assigns a value to an attribute, retrieve or generate another policy rule or call a certain function. If the result is a policy rule, then its condition needs to be resolved to determine the next action. This rule may be parsed locally or may be forwarded to another AAA service. o Service Equipment (SE) J. Salowey et al. Expires: September 2001 [Page 3]
Internet Draft Policies in AAA March 2001 Term used for equipment like (but not limited to) smart switches, routers, firewalls, bandwidth brokers, network access equipment, et cetera. 2 Policies The following sections provide terms for some aspects of policies, such as where they are located, where they are evaluated and what their purpose is. Please note that for a specific policy, more than one of the terms described below might apply. If this is the case, avoid ambiguities by combining the terms that apply. As an example, a policy that is stored on a remote AAA Service, is evaluated by the Generic RBE, but mainly interacts with an ASM to set some metering parameters can thus be described as a "Remote Application Specific Metering Policy". 2.1 Location of Policies Policies must be obtained before they can be evaluated. We break the location of policy into a few categories. Please note that policies cannot be labeled with these terms as if the location is an intristic aspect. It rather depends on the viewpoint you take. o Distributed Policy A Distributed Policy is a set of Local and/or Remote policies that all need to be evaluated to give an answer to a specific request. In a degenerated form it can be a single policy in one AAA Service, but it can also be multiple policies in the same AAA Service or in different AAA Services. o Local Policy A Policy stored in an AAA Service. This policy would have been provisioned to the service sometime in the past (for example by putting it into its Policy Repository), so it is available when it needs to be evaluated. o Remote Policy A Policy that is stored on a remote AAA Service. The policy may be obtained through push or pull mechanisms from the remote AAA Service so it may be evaluated locally. A Remote Policy may also be evaluated remotely at the request of the AAA service. J. Salowey et al. Expires: September 2001 [Page 4]
Internet Draft Policies in AAA March 2001 2.2 Distribution of Policies across Domains In complex environments it is possible for policies to be distributed across several AAA Domains. o Extra-domain Policy Is stored and administered in a foreign domain. It can be evaluated in the foreign domain in response to a request from the local domain. o Inter-domain Policy A Policy that crosses administrative domain boundaries, either by push or pull mechanisms. Inter-domain Policies may originate in a foreign domain and be evaluated in the local domain, or it may originate in the local domain and be evaluated in a foreign domain. If it is specific to Distributed Policies, then it means that the Distributed Policy consists of multiple Policies which do not all live in the same administrative domain. o Intra-domain Policy Originate from and are evaluated entirely within a single administrative domain. They may be distributed throughout multiple AAA services and policy repositories, however all of these are part of the same service provider domain. 2.3 Policy niche There is a big difference between Policies that are meant to be interpreted by different parts of an AAA Service. To make a clear distinction between those types of policies, the following terms are introduced: o Application Proprietary Policy In other cases the Policy is in a format or language that must be evaluated by an application specific RBE, in this case the Policy (and attributes) must be passed to the Application Specific Module to be evaluated. The AAA Service does not evaluate these policies, it only transports them. o Application Specific Policy A Policy that a generic RBE may be able to evaluate, but depends J. Salowey et al. Expires: September 2001 [Page 5]
Internet Draft Policies in AAA March 2001 heavily on interaction with an Application Specific Module. o Generic Policy A Policy that can be and is meant to be interpreted by the Rule Based Engine of the Generic AAA Server itself, not by any other component like an ASM or Service Equipment. 2.4 Policy types This section looks at various specific types of policy that an Generic AAA Architecture deals with directly or indirectly. The distinction between the policies in this section are not based on the place (niche) in the AAA environment where they live, but on their contents or purpose. o Accounting Policy Accounting Policies govern the generation, transportation and storage of accounting data. Accounting data may be used for trend analysis, capacity planning, and billing. o Attribute Conflict Policy It is possible that attributes may conflict. This may also be resolved by signaling an error condition, overriding, or intersection. It is also possible that an attribute may be expected to have more than one value. In other cases attributes may be out of range. How this is resolved is determined by the Attribute Conflict Policy. o Attribute Forwarding Policy In many cases it is important not to send attributes to another party for privacy reasons. Attribute Forwarding Policies determine which attributes can be forwarded, under what conditions and how they must be protected (perhaps encrypted so only an AAA Service at the end of the evaluation chain can read it). o Auditing Policy Auditing Policies deal with information that is collected for auditing purposes. Auditing verifies the correctness of operation. o Authentication Policy J. Salowey et al. Expires: September 2001 [Page 6]
Internet Draft Policies in AAA March 2001 An Authentication Policy has to deal with how authentication is performed. For example, in evaluating a certificate, such a policy may determine where CRL's are kept and how often they are re-issued. It may also determine how to deal with multi-byte character passwords. Authentication Policies are typically used where authentication is performed, however the Policy used during authentication may be used as context information when evaluating the Authorization Policy. For example, authorization policy may require information about what kind of authentication was used, whether CRL's were checked, forwarded Kerberos tickets were used, et cetera. o Authorization Policy Authorization Policies deal with granting different types of access to a particular object. Typically, an Authorization Policy statement is made up of the following: 1) Access identity: the identity of the entity requesting access. 2) Grantor identity: the identity of an entity granting permissions. 3) Access rights: the actions available to be performed on a certain object. 4) Conditions: additional criteria that must be met to grant the requested access. ACL based authorization uses access control lists associated with objects. The ACLs contain the identities allowed certain access to an object. Capability based authorization stores a list of grantors that can grant permission (capability) to certain access to an object. Evaluation of a Authorization Policy typically needs the identity of the accessor and/or the grantor. The identity may be authorized to take on group membership, which can be used along with or instead of the original identity. Identities may represent users, hosts, or applications. Identities do not have to be directly traceable back to the original entity they represent (this may be desirable for privacy reasons). Anonymous or anybody may be a valid identity in some systems. Authorization Policies that extend beyond more than one domain may be more complicated. Not only must the end user be authorized, but access to resources in other domains must be J. Salowey et al. Expires: September 2001 [Page 7]
Internet Draft Policies in AAA March 2001 authorized against service level agreements between domains. o Billing Policy Billing Policies deal with pricing and charging for service. o Boot Policy A Policy that will be retrieved from the Policy Repository and evaluated right after the AAA Service has started. It can be used to set default parameters on the AAA Service, ASMs and/or Service Equipment. o Configuration Policy In many cases policy rules and attributes must be presented in an application format so they can be processed by another device. A Configuration Policy determines how the results of one policy evaluation are translated into an application specific form so they can be evaluated by service equipment. o Driving Policy The first Policy that will be retrieved from the Policy Repository upon the reception of a Request. It might be that there is one Policy in an AAA Service that is always consulted first, or it might be that each time a different one is retrieved depending on the contents of the request. o Metering Policy Metering Policies govern how information about the usage of resources will be collected and measured. o Policy Conflict Policy In evaluating Policies conflicts may arise (see the definition of "policy conflicts" in [POLICY]). Conflicts may occur at the policy rule level where two rules conflict. For example it may be that one rule says "if it is past 11AM then Joe can have a beer" and another rule may say "if it is before 11AM then Joe can have a beer". Policy conflicts can be resolved in several ways. One may choose to error out and not evaluate the policy, one policy may override the other, or the policies may be intersected in some way ("Joe can have a beer as long as it is not exactly 11AM"). A Policy Conflict Policy determines how policy conflicts are J. Salowey et al. Expires: September 2001 [Page 8]
Internet Draft Policies in AAA March 2001 resolved in a system. Some policy conflicts can be resolved in a Generic RBE. In other cases specific knowledge of the application is needed to resolve the conflict. o Privacy Policy Privacy Policies deal with how and to whom collected data is disclosed. For example a Privacy Policy may dictate that actual user identities may not be directly traceable to a particular session without the cooperation of the user's home organization. o Registration Policy Registration Policies deals with how users and other entities are registered on the network and how credentials are created and distributed. One example of Registration Policy is a password policy: how often are passwords renewed, how long must a password be, how many characters, is there a dictionary check, et cetera. Another example of Registration Policy is the policy associated with a PKI: how is the identity of a user verified when the certificate is issued, what is in the certificates et cetera. o Security Policy Security Policies govern the requirements for secure transactions. This type of policy creates additional requirements for the above policies. For example it may require that strong authentication always be used and that all data must be encrypted when traversing a network. o Service Allocation Policy One of the conditions authorization to a service may depend upon is the current utilization and availability of a service. An AAA service would evaluate service allocation before allowing access to a service. It verifies whether the resources requested are available and may specify rules to follow if they are becoming scarce. Some examples: 1) if utilization<.7 then Answer=Yes else if utilization <.8 and PrivilegeClass>1 then Answer=Yes else if utilization <.9 and PrivilegeClass>2 then Answer=Yes else Answer=No 2) if Status(Queue1)=NotCongested then Queue=1 else if Status(Queue2)=NotCongested then Queue=2 else Queue=3 J. Salowey et al. Expires: September 2001 [Page 9]
Internet Draft Policies in AAA March 2001 o Service Specification Policy This type of Policy is specified by the user and determines what service is desired under what conditions. For example a user may say: if (cost < 50) request = 100 else request 10 3. Policy components Policies are made up of several components, and although we do not give a description of how policies are made or look like, we can identify some parts that will definitely belong to any Policy: o Policy Action Something that effectively tells some Service Equipment to really do something. It can be a parameter that is changed or a command that is given to an ASM to effectuate this. o Policy Attribute Any data element that can be processed by a Policy Rule. For example, an Attribute Value Pair that was supplied in a request, or an application specific attribute that was retrieved through an ASM. o Policy Condition A boolean expression, for example like "(bandwidth > 50) AND accesslevel = 10". o Policy Rule Almost anything you can describe with an if..then..else clause. References [AAAARCH] Authorization, Authentication and Accounting ARCHitecture research group, http://www.phys.uu.nl/~wwwfi/aaaarch/ [OBJMSG] D. Spence, "Data Objects and Message Types in the Generic AAA Architecture", draft-spence-aaaarch-objmsg-00.txt, January 2001 [POLICY] A. Westerinen et al., "Policy Terminology", draft-ietf- policy-terminology-02.txt, February 2001 J. Salowey et al. Expires: September 2001 [Page 10]
Internet Draft Policies in AAA March 2001 [POLICYACCT] G. Carle, S. Zander and T. Zseby, "Policy-based Accounting", draft-irtf-aaaarch-pol-acct-01.txt, September 2000 [POLICYMODEL] A. Taal, G. Sliepen and D. Spence, "Policies in AAA", draft-taal-aaaarch-generic-pol-01.txt, March 2001 [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. Vollbrecht, "Generic AAA Architecture", RFC 2903, August 2000 [RFC2904] J. Vollbrecht et al., "AAA Authorization Framework", RFC 2904, August 2000 Authors' Addresses Joseph Salowey Cisco Systems Building 20 725 Alder Drive Milpitas, CA 95035 USA Phone: +1 408 525 6381 Email: jsalowey@cisco.com Guus Sliepen Physics and Astronomy department Utrecht University Pincetonplein 5 3584 CC Utrecht Netherlands Phone: +31 30 2537724 Phone: +31 30 2537555 Email: sliepen@phys.uu.nl Arie Taal Physics and Astronomy department Utrecht University Pincetonplein 5 3584 CC Utrecht Netherlands Phone: +31 30 2537556 Phone: +31 30 2537555 Email: taal@phys.uu.nl J. Salowey et al. Expires: September 2001 [Page 11]
Internet Draft Policies in AAA March 2001 David W. Spence Interlink Networks, Inc. 775 Technology Drive, Suite 200 Ann Arbor, MI 48108 USA Phone: +1 734 821 1203 Fax: +1 734 821 1235 Email: dspence@interlinknetworks.com J. Salowey et al. Expires: September 2001 [Page 12]
--
