Internet Draft J. Salowey November 20000 [...] Expires in 6 months G. Sliepen A. Taal Utrecht University D. Spence Interlink Networks, Inc. Policy in AAA Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This document discusses policy as it relates to a AAA framework. The first section looks at a generic policy description and tries to define terminology to categorize policies. The second section looks at the various types of policy that come into play in a AAA system. 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]. 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 policy descriptions 1.1 The AAA framework The goal of a AAA framework is to control access to and provide authentication, authorization and accounting for system based on the policies set by the administrators and users of the system. Much of this section is based on [RFC2903]. A AAA Service is a service that performs one or more of the following functions: Accounting, Authentication and Authorization. A AAA service is contained within a single device and is not spread across multiple servers. A AAA server such as a RADIUS server is an example of a AAA service. The definition of a AAA service is broader that that of a AAA server, for example it also includes service equipment that authorizes use based on evaluating various policies. A AAA Domain is a collection of one or more AAA owned by a same organizational entity. Every AAA service belongs to one AAA domain, but a AAA domain can contain many services. Policies are expressed as policy rules. A "simple" policy rule [POLICY] 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. The AAA context contains information that is accessible to the RBE in the form of attributes associated with values. Attributes may originate within a AAA service or they may be obtained from another AAA service or policy information point. A AAA service may forward attributes on to another AAA service. A AAA service may obtain policy rules from another source or it may defer the evaluation of policy to another AAA service. 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 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. 1.2 Location of policy Policy must be obtained before it can be evaluated. We break the location of policy into two categories local policy and remote policy. Local Policy is stored in a AAA Service. This policy would have been provisioned to the service sometime in the past so it is available when it needs to be evaluated. Remote Policy is stored away from the AAA service. The policy may be obtained through push or pull mechanisms from another AAA service or a policy repository so it may be evaluated locally. Policy may also be evaluated remotely at the request of the AAA service. A Distributed Policy is a set of Local and 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. 1.3 Distribution of policy across domains In complex environments it is possible for policies to be distributed across several AAA domains. Intra-domain policies originate 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. Inter-domain policy 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. Extra-domain policy is stored and administered in a foreign domain. It is evaluated in the foreign domain in response to a request from the local domain. (is there a significant difference between inter and extra policies?) 1.3 Policy Rule evaluation In some cases the policy can be evaluated by a generic rule based engine without needing to know anything additional about the application. This policy is generic policy. In other cases a generic RBE may be able to evaluate the policy rule, but it needs to retrieve attributes from an application specific module. This policy is application specific policy. In other cases the policy rule 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. This is application proprietary policy. The generic AAA framework does not evaluate these policies it only transports them. 1.4 Policy Conflicts In evaluating policy conflicts may arise. 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") Policy Conflict policy determines how policy conflicts are 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. 1.5 Attribute policies It is also possible that attributes may conflict. This may also be resolved by an 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 attribute conflict policy. In many cases it is important not to send attributes to another party for privacy reasons. Attribute forwarding policy determines which attributes can be forwarded, under what conditions and how they must be protected (perhaps encrypted so only a AAA service at the end of the evaluation can read it). 1.6 Policy Translation In many cases policy rules and attributes must be presented in an application format so they can be processed by another device. 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. 2. Specific Types of policy This section looks at various specific types of policy that a AAA framework deals with directly or indirectly. 2.1 Registration Policy Registration policy 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 password policy: how often are passwords renewed, how long must a password be, how many characters, is there a dictionary check, etc. 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 etc. Registration policy is typically outside the scope of a AAA framework since the user of a server is already registered with the network. Registered entities then become the subject of authentication policy. Registration may also have some effect on authorization policy as well. 2.2 Authentication Policy Authentication policy has to deal with how authentication is performed. For example, in evaluating a certificate chain 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 policy is typically used where authentication is performed, however the policy used during authentication may be used as context information when evaluating 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, etc. 2.3 Authorization policy Authorization policy deals 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. Evaluating 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 policy that extends 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 authorized against service level agreements between domains. 2.3.1 Service Allocation Policy One of the conditions authorization to a service may depend upon is the current utilization and availability of a service. A 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 2.4 Accounting policy Accounting policy governs the generation, transportation and storage of accounting data. Accounting data may be used for trend analysis, capacity planning, and billing. 2.4.1 Metering policy Metering policy that governs how information about the usage of resources will be collected and measured. 2.4.2 Billing Policy Billing policy that deals with pricing and charging for service. 2.5 Service Specification Policy This type of policy is specified by the user and determines what service is desired under what conditions. For example a use may say If (cost < 50) request = 100 else request 10 2.5 Auditing policy Policy dealing with information that is collected for auditing purposes. Auditing verifies the correctness of operation. 2.6 Privacy Policy Policy that deals with how and to whom collected data is disclosed. For example 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. 2.7 Security Policy Policy that governs 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. References [AAAARCH] Authorization, Authentication and Accounting ARCHitecture research group http://www.phys.uu.nl/~wwwfi/aaaarch/ [POLICYMODEL] Taal, A., "Policies in AAA", http://www.phys.uu.nl/~wwwfi/aaaarch/ [POLICYACCT] G. Carle, S. Zander , T. Zseby, "Policy-based Accounting", IRTF Draft, draft-irtf-aaaarch-pol-acct-01.txt, September 2000 [RFC2903] de Laat, C., Gommans, L., Gross, G, D. Spence, and Vollbrecht, J, "Generic AAA Architecture", RFC 2903, August 2000. [POLICY] Westerinen, A ,et al, "Policy Terminology", draft-ietf- policy-terminology-00.txt, July 2000 Authors' Addresses Joseph Salowey USA Email: jsalowey@qwest.net Guus Sliepen Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands Phone: +31 30 2537724 Phone: +31 30 2537555 EMail: g.sliepen@phys.uu.nl Arie Taal Physics and Astronomy dept. Utrecht University Pincetonplein 5, 3584CC Utrecht Netherlands Phone: +31 30 2537556 Phone: +31 30 2537555 EMail: taal@phys.uu.nl 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