idnits 2.17.1 draft-irtf-aaaarch-aaa-pol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 37 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([AAAARCH], [POLICYMODEL], [POLICY], [POLICYACCOUNTING]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2001) is 8443 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'POLICY MODEL' on line 41 looks like a reference -- Missing reference section? 'POLICY ACCOUNTING' on line 42 looks like a reference -- Missing reference section? 'POLICY' on line 473 looks like a reference -- Missing reference section? 'AAAARCH' on line 467 looks like a reference -- Missing reference section? 'RFC2903' on line 482 looks like a reference -- Missing reference section? 'OBJMSG' on line 470 looks like a reference -- Missing reference section? 'RFC2904' on line 485 looks like a reference -- Missing reference section? 'POLICYACCT' on line 476 looks like a reference -- Missing reference section? 'POLICYMODEL' on line 479 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J. Salowey 2 draft-irtf-aaaarch-aaa-pol-01.txt G. Sliepen 3 A. Taal 4 D. Spence 5 March 2001 7 Policies in AAA 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2000). All Rights Reserved. 33 Abstract 35 This document defines some terms related to the Generic AAA 36 architecture. The first section describes some broad aspects of such 37 an architecture. The second section looks at the various aspects and 38 types of policy that come into play in an AAA architecture. The 39 third section will describe some of the components of a single 40 policy. This work is preliminary and is expected to be complimented 41 by other work from the AAAARCH research group such as [POLICY MODEL] 42 and [POLICY ACCOUNTING]. 44 This document is also meant as an extension to the [POLICY] document 45 from the Policy Framework working group. Some terms from the 46 [POLICY] document are also defined in this document, to make it more 47 self-contained. Where possible, the meaning of the terms has been 48 kept the same. Please note however that the primary focus of this 49 document is the AAAARCH research group, and hence some descriptions 50 may deviate from those given in the [POLICY] document. 52 Comments on this document should be sent to the mailing list of the 53 IRTF AAA architecture [AAAARCH] mailing list: aaaarch@fokus.gmd.de. 55 1. Generic descriptions 57 1.1 The Generic AAA Architecture 59 The goal of the Generic AAA Architecture is to control and provide 60 authentication, authorization and accounting for systems and 61 environments based on the policies set by the administrators and 62 users of the system. Much of this section is based on [RFC2903]. The 63 following terms specify some of the broader aspects of the generic 64 AAA architecture: 66 o AAA Domain 68 A single administrative domain. Contains a collection of one or 69 more AAA services owned by the same organizational entity. Note 70 that every AAA Service belongs to one AAA domain, but an AAA 71 domain can contain many AAA Services. Note that this is 72 slightly different from a "policy domain" as defined in 73 [POLICY]. 75 o AAA Server / AAA Service 77 A Service that performs one or more of the following functions: 78 accounting, authentication and authorization. An AAA Server is 79 contained within a single device and is not spread across 80 multiple servers. An AAA Server such as a RADIUS server is an 81 example of an AAA service. The definition of an AAA Service is 82 broader than that of an AAA Server, for example it also includes 83 Service Equipment that authorizes use based on evaluating 84 various Policies. 86 o Application Specific Module (ASM) 88 A component of an AAA Service that allows Policies to influence 89 Service Equipment. Service Equipment can be anything, and 90 therefore there is no standard API to communicate with. An ASM 91 however does have a standard API, and it can be used to 92 translate requests into something the Service Equipment 93 understands. 95 o Policy 97 As defined in [POLICY]: 99 1. A definite goal, course or method of action to guide and 100 determine present and future decisions. "Policies" are 101 implemented or executed within a particular context (such as 102 policies defined within a business unit). 104 2. Policies as a set of rules to administer, manage, and 105 control access to network resources. 107 In the Generic AAA Architecture, Policies are expressed as 108 policy rules. A "simple" policy rule consists of a policy 109 condition and a policy action. The policy condition is evaluated 110 and depending on the evaluation of the condition a policy action 111 is taken or not. A RBE will evaluate the policy condition to 112 take a policy decision. Based on the outcome, the RBE will 113 execute the policy action. 115 o Request 117 A Request is any kind of message that asks for a service. There 118 are lots of different requests (see [OBJMSG]), and many ways to 119 send a request to the service, for example via the push, pull or 120 agent model as described in [RFC2904]. A Request will initiate 121 the evaluation of one or more Policies, which may execute some 122 Actions and return a response. 124 o Rule Based Engine (RBE) 126 A RBE may be generic and able to process rules of a given type 127 with little or no knowledge of an application. In other cases 128 the RBE may be application specific. In general, a RBE in 129 service equipment is application specific. A generic RBE may 130 enlist the help of an Application Specific Module (ASM) to 131 evaluate some policies. 133 A policy decision may result in either a true or false, which 134 may then result in an action that assigns a value to an 135 attribute, retrieve or generate another policy rule or call a 136 certain function. If the result is a policy rule, then its 137 condition needs to be resolved to determine the next action. 138 This rule may be parsed locally or may be forwarded to another 139 AAA service. 141 o Service Equipment (SE) 142 Term used for equipment like (but not limited to) smart 143 switches, routers, firewalls, bandwidth brokers, network access 144 equipment, et cetera. 146 2 Policies 148 The following sections provide terms for some aspects of policies, 149 such as where they are located, where they are evaluated and what 150 their purpose is. Please note that for a specific policy, more than 151 one of the terms described below might apply. If this is the case, 152 avoid ambiguities by combining the terms that apply. 154 As an example, a policy that is stored on a remote AAA Service, is 155 evaluated by the Generic RBE, but mainly interacts with an ASM to set 156 some metering parameters can thus be described as a "Remote 157 Application Specific Metering Policy". 159 2.1 Location of Policies 161 Policies must be obtained before they can be evaluated. We break the 162 location of policy into a few categories. Please note that policies 163 cannot be labeled with these terms as if the location is an intristic 164 aspect. It rather depends on the viewpoint you take. 166 o Distributed Policy 168 A Distributed Policy is a set of Local and/or Remote policies 169 that all need to be evaluated to give an answer to a specific 170 request. In a degenerated form it can be a single policy in one 171 AAA Service, but it can also be multiple policies in the same 172 AAA Service or in different AAA Services. 174 o Local Policy 176 A Policy stored in an AAA Service. This policy would have been 177 provisioned to the service sometime in the past (for example by 178 putting it into its Policy Repository), so it is available when 179 it needs to be evaluated. 181 o Remote Policy 183 A Policy that is stored on a remote AAA Service. The policy may 184 be obtained through push or pull mechanisms from the remote AAA 185 Service so it may be evaluated locally. A Remote Policy may also 186 be evaluated remotely at the request of the AAA service. 188 2.2 Distribution of Policies across Domains 190 In complex environments it is possible for policies to be distributed 191 across several AAA Domains. 193 o Extra-domain Policy 195 Is stored and administered in a foreign domain. It can be 196 evaluated in the foreign domain in response to a request from 197 the local domain. 199 o Inter-domain Policy 201 A Policy that crosses administrative domain boundaries, either 202 by push or pull mechanisms. Inter-domain Policies may originate 203 in a foreign domain and be evaluated in the local domain, or it 204 may originate in the local domain and be evaluated in a foreign 205 domain. 207 If it is specific to Distributed Policies, then it means that 208 the Distributed Policy consists of multiple Policies which do 209 not all live in the same administrative domain. 211 o Intra-domain Policy 213 Originate from and are evaluated entirely within a single 214 administrative domain. They may be distributed throughout 215 multiple AAA services and policy repositories, however all of 216 these are part of the same service provider domain. 218 2.3 Policy niche 220 There is a big difference between Policies that are meant to be 221 interpreted by different parts of an AAA Service. To make a clear 222 distinction between those types of policies, the following terms are 223 introduced: 225 o Application Proprietary Policy 227 In other cases the Policy is in a format or language that must 228 be evaluated by an application specific RBE, in this case the 229 Policy (and attributes) must be passed to the Application 230 Specific Module to be evaluated. The AAA Service does not 231 evaluate these policies, it only transports them. 233 o Application Specific Policy 235 A Policy that a generic RBE may be able to evaluate, but depends 236 heavily on interaction with an Application Specific Module. 238 o Generic Policy 240 A Policy that can be and is meant to be interpreted by the Rule 241 Based Engine of the Generic AAA Server itself, not by any other 242 component like an ASM or Service Equipment. 244 2.4 Policy types 246 This section looks at various specific types of policy that an 247 Generic AAA Architecture deals with directly or indirectly. The 248 distinction between the policies in this section are not based on the 249 place (niche) in the AAA environment where they live, but on their 250 contents or purpose. 252 o Accounting Policy 254 Accounting Policies govern the generation, transportation and 255 storage of accounting data. Accounting data may be used for 256 trend analysis, capacity planning, and billing. 258 o Attribute Conflict Policy 260 It is possible that attributes may conflict. This may also be 261 resolved by signaling an error condition, overriding, or 262 intersection. It is also possible that an attribute may be 263 expected to have more than one value. In other cases attributes 264 may be out of range. How this is resolved is determined by the 265 Attribute Conflict Policy. 267 o Attribute Forwarding Policy 269 In many cases it is important not to send attributes to another 270 party for privacy reasons. Attribute Forwarding Policies 271 determine which attributes can be forwarded, under what 272 conditions and how they must be protected (perhaps encrypted so 273 only an AAA Service at the end of the evaluation chain can read 274 it). 276 o Auditing Policy 278 Auditing Policies deal with information that is collected for 279 auditing purposes. Auditing verifies the correctness of 280 operation. 282 o Authentication Policy 283 An Authentication Policy has to deal with how authentication is 284 performed. For example, in evaluating a certificate, such a 285 policy may determine where CRL's are kept and how often they are 286 re-issued. It may also determine how to deal with multi-byte 287 character passwords. Authentication Policies are typically used 288 where authentication is performed, however the Policy used 289 during authentication may be used as context information when 290 evaluating the Authorization Policy. For example, authorization 291 policy may require information about what kind of authentication 292 was used, whether CRL's were checked, forwarded Kerberos tickets 293 were used, et cetera. 295 o Authorization Policy 297 Authorization Policies deal with granting different types of 298 access to a particular object. Typically, an Authorization 299 Policy statement is made up of the following: 301 1) Access identity: the identity of the entity requesting 302 access. 304 2) Grantor identity: the identity of an entity granting 305 permissions. 307 3) Access rights: the actions available to be performed on a 308 certain object. 310 4) Conditions: additional criteria that must be met to grant the 311 requested access. 313 ACL based authorization uses access control lists associated 314 with objects. The ACLs contain the identities allowed certain 315 access to an object. Capability based authorization stores a 316 list of grantors that can grant permission (capability) to 317 certain access to an object. 319 Evaluation of a Authorization Policy typically needs the 320 identity of the accessor and/or the grantor. The identity may be 321 authorized to take on group membership, which can be used along 322 with or instead of the original identity. Identities may 323 represent users, hosts, or applications. Identities do not have 324 to be directly traceable back to the original entity they 325 represent (this may be desirable for privacy reasons). Anonymous 326 or anybody may be a valid identity in some systems. 328 Authorization Policies that extend beyond more than one domain 329 may be more complicated. Not only must the end user be 330 authorized, but access to resources in other domains must be 331 authorized against service level agreements between domains. 333 o Billing Policy 335 Billing Policies deal with pricing and charging for service. 337 o Boot Policy 339 A Policy that will be retrieved from the Policy Repository and 340 evaluated right after the AAA Service has started. It can be 341 used to set default parameters on the AAA Service, ASMs and/or 342 Service Equipment. 344 o Configuration Policy 346 In many cases policy rules and attributes must be presented in 347 an application format so they can be processed by another 348 device. A Configuration Policy determines how the results of 349 one policy evaluation are translated into an application 350 specific form so they can be evaluated by service equipment. 352 o Driving Policy 354 The first Policy that will be retrieved from the Policy 355 Repository upon the reception of a Request. It might be that 356 there is one Policy in an AAA Service that is always consulted 357 first, or it might be that each time a different one is 358 retrieved depending on the contents of the request. 360 o Metering Policy 362 Metering Policies govern how information about the usage of 363 resources will be collected and measured. 365 o Policy Conflict Policy 367 In evaluating Policies conflicts may arise (see the definition 368 of "policy conflicts" in [POLICY]). Conflicts may occur at the 369 policy rule level where two rules conflict. For example it may 370 be that one rule says "if it is past 11AM then Joe can have a 371 beer" and another rule may say "if it is before 11AM then Joe 372 can have a beer". Policy conflicts can be resolved in several 373 ways. One may choose to error out and not evaluate the policy, 374 one policy may override the other, or the policies may be 375 intersected in some way ("Joe can have a beer as long as it is 376 not exactly 11AM"). 378 A Policy Conflict Policy determines how policy conflicts are 379 resolved in a system. Some policy conflicts can be resolved in a 380 Generic RBE. In other cases specific knowledge of the 381 application is needed to resolve the conflict. 383 o Privacy Policy 385 Privacy Policies deal with how and to whom collected data is 386 disclosed. For example a Privacy Policy may dictate that actual 387 user identities may not be directly traceable to a particular 388 session without the cooperation of the user's home organization. 390 o Registration Policy 392 Registration Policies deals with how users and other entities 393 are registered on the network and how credentials are created 394 and distributed. One example of Registration Policy is a 395 password policy: how often are passwords renewed, how long must 396 a password be, how many characters, is there a dictionary check, 397 et cetera. Another example of Registration Policy is the policy 398 associated with a PKI: how is the identity of a user verified 399 when the certificate is issued, what is in the certificates et 400 cetera. 402 o Security Policy 404 Security Policies govern the requirements for secure 405 transactions. This type of policy creates additional 406 requirements for the above policies. For example it may require 407 that strong authentication always be used and that all data must 408 be encrypted when traversing a network. 410 o Service Allocation Policy 412 One of the conditions authorization to a service may depend upon 413 is the current utilization and availability of a service. An AAA 414 service would evaluate service allocation before allowing access 415 to a service. It verifies whether the resources requested are 416 available and may specify rules to follow if they are becoming 417 scarce. Some examples: 419 1) if utilization<.7 then Answer=Yes 420 else if utilization <.8 and PrivilegeClass>1 then Answer=Yes 421 else if utilization <.9 and PrivilegeClass>2 then Answer=Yes 422 else Answer=No 424 2) if Status(Queue1)=NotCongested then Queue=1 425 else if Status(Queue2)=NotCongested then Queue=2 426 else Queue=3 428 o Service Specification Policy 430 This type of Policy is specified by the user and determines what 431 service is desired under what conditions. For example a user may 432 say: 434 if (cost < 50) request = 100 435 else request 10 437 3. Policy components 439 Policies are made up of several components, and although we do not 440 give a description of how policies are made or look like, we can 441 identify some parts that will definitely belong to any Policy: 443 o Policy Action 445 Something that effectively tells some Service Equipment to 446 really do something. It can be a parameter that is changed or a 447 command that is given to an ASM to effectuate this. 449 o Policy Attribute 451 Any data element that can be processed by a Policy Rule. For 452 example, an Attribute Value Pair that was supplied in a request, 453 or an application specific attribute that was retrieved through 454 an ASM. 456 o Policy Condition 458 A boolean expression, for example like "(bandwidth > 50) AND 459 accesslevel = 10". 461 o Policy Rule 463 Almost anything you can describe with an if..then..else clause. 465 References 467 [AAAARCH] Authorization, Authentication and Accounting ARCHitecture 468 research group, http://www.phys.uu.nl/~wwwfi/aaaarch/ 470 [OBJMSG] D. Spence, "Data Objects and Message Types in the Generic 471 AAA Architecture", draft-spence-aaaarch-objmsg-00.txt, January 2001 473 [POLICY] A. Westerinen et al., "Policy Terminology", draft-ietf- 474 policy-terminology-02.txt, February 2001 476 [POLICYACCT] G. Carle, S. Zander and T. Zseby, "Policy-based 477 Accounting", draft-irtf-aaaarch-pol-acct-01.txt, September 2000 479 [POLICYMODEL] A. Taal, G. Sliepen and D. Spence, "Policies in AAA", 480 draft-taal-aaaarch-generic-pol-01.txt, March 2001 482 [RFC2903] C. de Laat, L. Gommans, G. Gross, D. Spence and J. 483 Vollbrecht, "Generic AAA Architecture", RFC 2903, August 2000 485 [RFC2904] J. Vollbrecht et al., "AAA Authorization Framework", RFC 486 2904, August 2000 488 Authors' Addresses 490 Joseph Salowey 491 Cisco Systems 492 Building 20 493 725 Alder Drive 494 Milpitas, CA 95035 495 USA 497 Phone: +1 408 525 6381 498 Email: jsalowey@cisco.com 500 Guus Sliepen 501 Physics and Astronomy department 502 Utrecht University 503 Pincetonplein 5 504 3584 CC Utrecht 505 Netherlands 507 Phone: +31 30 2537724 508 Phone: +31 30 2537555 509 Email: sliepen@phys.uu.nl 511 Arie Taal 512 Physics and Astronomy department 513 Utrecht University 514 Pincetonplein 5 515 3584 CC Utrecht 516 Netherlands 518 Phone: +31 30 2537556 519 Phone: +31 30 2537555 520 Email: taal@phys.uu.nl 521 David W. Spence 522 Interlink Networks, Inc. 523 775 Technology Drive, Suite 200 524 Ann Arbor, MI 48108 525 USA 527 Phone: +1 734 821 1203 528 Fax: +1 734 821 1235 529 Email: dspence@interlinknetworks.com 531 --