One document matched: draft-irtf-aaaarch-aaa-pol-00.txt

Internet Draft                                                J. Salowey
November 20000							   [...]
Expires in 6 months                                           G. Sliepen
                                                                 A. Taal
                                                      Utrecht University
                                                               D. Spence
                                                Interlink Networks, Inc.



                          Policy in AAA
                 
               <draft-irtf-aaaarch-aaa-pol-00.txt>



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