[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

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]

--


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/