idnits 2.17.1 draft-ietf-cat-acc-cntrl-frmw-04.txt: ** The Abstract section seems to be numbered 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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1085 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 38 instances of too long lines in the document, the longest one being 23 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 170 has weird spacing: '...allowed if ce...' == Line 344 has weird spacing: '...ty used to sp...' == Line 637 has weird spacing: '...ontains misce...' == Line 809 has weird spacing: '...horized and d...' == Line 824 has weird spacing: '...SSL or authen...' == (5 more instances...) -- 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 (July 11, 2000) is 8689 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) == Unused Reference: '2' is defined on line 1034, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1038, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1052, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Tatyana Ryutov 2 CAT Working Group Clifford Neuman 3 Expires January 2001 USC/Information Sciences Institute 4 draft-ietf-cat-acc-cntrl-frmw-04.txt July 11, 2000 6 Access Control Framework for Distributed Applications 8 0. Status Of this Document 10 This document is an Internet-Draft and is in full conformance 11 with all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as 21 "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 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 34 (US West Coast). 36 1. Abstract 38 This document describes a unified model to support authorization in a 39 wide range of applications, including metacomputing, remote printing, 40 video conference, and any other application which will require 41 interactions between entities across autonomous security domains. 43 The document proposes requirements for the support of: 45 - flexible and expressive mechanism for representing 46 and evaluating security policies 48 - uniform authorization service interface for facilitating access 49 control decisions for applications and requesting access control 50 information about a particular resource. 52 This specification defines structures and their uses at a level 53 independent of underlying mechanism and programming language environment. 54 This document is accompanied by a second one describing the details of 55 proposed structures and services along with bindings for C language 56 environments. This document is to be found in 57 draft-ietf-cat-gaa-cbind-04.txt. 59 2. Introduction 61 The variety of services available on the Internet continues to increase 62 and new classes of applications such as metacomputing, remote printing, 63 video conference is evolving. These applications will require 64 interactions between entities across autonomous security domains. 66 The distributed nature of the system, consisting of mutually suspicious 67 security domains, requires a mechanism, which provides fine-grained 68 access control to resources. 70 For example, access control requirements of a remote printing application 71 may include: 73 - authorized individual users and organizations 74 - time availability, e.g. time of the day or day of the week 75 - restrictions on resources consumed by the clients, e.g. maximum 76 job size, maximum number of pages per job 77 - required confidentiality/integrity message protection 78 - accounting for consumed resources 80 Access control requirements of large-scale multicast application [4], 81 e.g. corporate video conference may include: 83 - authorized individual users and organizations 84 - host properties; users on slow hosts or hosts running the wrong 85 OS will be denied communication 86 - accounting for consumed resources 88 Some of the security requirements are common across different 89 applications, while others are more individual. 91 Access control policies can be formulated in many ways. Administrators 92 Of each domain might use domain-specific policy syntax and 93 heterogeneous implementations of the policies. 95 It is necessary to define a particular framework applicable for 96 a wide range of systems and applications, which will allow to discuss 97 specific requirements for the representation and evaluation of security 98 policies. 99 An application developer should not have to give anything up by using 100 this framework, therefore the framework should provide support for 101 integration with existing OS or toolkit provided access control 102 mechanisms. 103 High-speed implementations should be provided for operations that are 104 supported natively by the underlying system. 106 The focus of this framework is based on the following two abstractions: 108 1) uniform mechanism for representation and evaluation of security 109 policies 111 It should be capable of implementing a number of different security 112 policies, based on diverse authorization models, which can coexist in 113 distributed system. Standardizing the way that applications define their 114 security requirements provides the means for integration of local and 115 distributed security policies and translation of security policies 116 across multiple authorization models. 118 The mechanism should support the common authorization requirements but 119 provide the means to defining and integration with application or 120 organization specific policies as well. Applications should not need to 121 re-implement the basic authorization functions in an 122 application-specific manner. 124 2) Generic Authorization and Access control Application Program 125 Interface (GAA-API) 127 A common API will facilitate authorization decisions for applications. 128 An application invokes the API functions to determine if a requested 129 operation or set of operation are authorized or if additional checks 130 are necessary. 132 The API will support the needs of most applications, thus not forcing 133 the developers to design their own authorization mechanisms. 134 The API will allow better integration of multiple mechanisms with 135 application servers. The GSS API can be used by the GAA-API to 136 obtain principal's identity see section 11. 138 Section 12 gives an extended example how the GAA-API can be used by 139 applications. 141 3. Glossary 143 OBJECT (RESOURCE) 144 entity that has to be protected e.g. hosts, files. 146 SUBJECT 147 entity that can initiate requests to an object e.g. individual users, 148 hosts, applications and groups. 150 PRINCIPAL 151 identity associated with a subject as a result of some unspecified 152 authentication protocol. It can refer to a person, group, host, and 153 application. Several principals can be associated with the same 154 subject. 156 SECURITY POLICY 157 the set of rules that govern access to objects 159 ACCESS RIGHT (OPERATION, PERMISSION) 160 a particular type of access to a protected object e.g. read, write, 161 and execute 163 RESTRICTION (CONDITION) 164 a specific policy allowing an operation to be performed on an 165 object 167 This policy can have two meanings: 169 1) descriptive 170 An operation is allowed if certain condition is satisfied. 171 For instance, a policy may require concurrence of two 172 principals to perform some operation. If participation of 173 both principals can be proved then this policy is satisfied. 175 2) prescriptive 176 An operation will be allowed if certain restrictive policy 177 is enforced. 179 For example, a process will be authorized to run on a host 180 if the memory usage limits that a process can occupy in main 181 memory satisfies certain constraints. Continuous evaluation of 182 restriction is required. 184 DELEGATION 185 is the ability of a principal to give to another principal limited 186 authority to act on its behalf. 188 CREDENTIAL 189 a statement of identity, group membership and non-membership, 190 privilege attribute and transfer of privilege encoded in 191 certificates. 193 4. Architecture 195 The major components of the architecture are: 197 Authentication mechanisms (perhaps involving an authentication 198 server) perform authentication of users and supply them with 199 initial credentials. 201 A group server is trusted to maintain and provide group membership 202 information. A group is a convenient method to associate a name with 203 a set of principals for access control purposes. A group server issues 204 group membership and non-membership certificates. When a connection is 205 established with an application server, these certificates are evaluated 206 (evaluation may be deferred until needed) the results are placed into 207 the GAA-API security context. They are checked by the GAA-API when 208 making authorization decisions. 210 The application calls the GAA-API routines to check authorization 211 against the application authorization model. 212 These routines obtain access control information from local 213 files, distributed authorization servers, and from credentials 214 provided by the user, combining local and distributed authorizations 215 under a single API according to the requirements of the application. 217 Delegation is supported through inclusion of delegated credentials. 218 Mechanism for delegation such as those supported by 219 restricted proxies [1] in the security context, where they are 220 available for use by authentication and authorization mechanisms 221 used for subsequent connections from the server (now acting as an 222 intermediary) to another server. 224 5. Objects 226 The purpose of access control is protecting objects from unauthorized 227 access. The kinds of objects to be protected are specific to the 228 application to which the authorization model is applied and are not 229 included into the authorization model. 230 The objects that need to be protected include files, directories, 231 network connections, hosts, auxiliary devices, e.g. printers and 232 faxes, and other entities. An authorization mechanism should support these 233 different kinds of objects in a uniform manner. Same security attribute 234 structure should be used to specify access policies for different kinds of 235 objects. 236 Object names should be drawn from the application-specific name space 237 and must be opaque to the authorization mechanism. 239 6. Security policy representation 241 One may think about the security policy associated with a protected 242 resource as a set of operations which a defined set of principals 243 is allowed to perform on the target resource, and optional constraints 244 placed on the granted operations. For example, a system administrator 245 can define the following security policy to govern access to a 246 printer: "Joe Smith and members of Department1 are allowed to print 247 documents Monday through Friday, from 9:00AM to 6:00PM". 248 This policy can be described by an ACL mechanism, where for each 249 resource, a list of valid entities is granted a set of access rights. 250 The same policy can be implemented using a capability mechanism. 251 However, traditional ACL and capability abstractions should be 252 extended to allow conditional restrictions on access rights. 254 Therefore, in implementing a policy, it should be possible to 255 define: 256 1) access identity 257 2) grantor identity 258 3) a set of access rights 259 4) a set of conditions 261 Policy is represented by a sequence of tokens. Each token consists of: 263 Token Type 265 Defines the type of the attribute. Tokens of the same type 266 have the same authorization semantics. 268 Defining Authority 270 It indicates the authority responsible for defining the value 271 within the attribute type. 273 Value 275 The value of the security attribute. Its syntax is determined by 276 the attribute type. The name space for the value is defined by 277 the Defining Authority field 279 6.1. Access identity 281 The access identity represents an identity to be used for access 282 control purposes. The authorization framework should support the 283 following kinds of access identity: 285 1) USER 286 identifies a person, e.g. authenticated user name. 288 2) HOST 289 identifies a subject as a machine from which request to access 290 the object was originated, e.g., an IP address or host DNS name 291 or host public key. 293 3) APPLICATION 294 identifies a certain program that has its own associated identity 295 (principal),e.g., a checksum or certified name. 296 This can be useful to grant access to a certain application, 297 e.g. payment program, that is trusted to be written correctly and 298 perform only its intended purpose. 300 4) CA 301 identifies a Certification Authority responsible for issuing a 302 certificate. 304 5) GROUP 305 identifies a group of subjects. The kind of subjects 306 (individual user, host or application) composing the group is 307 opaque to the authorization mechanism. 309 6) ANYBODY 310 represents any subject regardless of authentication. 311 This may be useful for setting the default policies. 313 The framework should support multiple existing principal naming 314 methods. Different administrative domains might use different 315 authentication mechanisms, each having a particular syntax for 316 specification of principals. Therefore, Defining Authority for access 317 identity indicates underlying authentication mechanism used to provide 318 the principal identity. Value represents particular principal identity. 320 Examples of access identities are: 322 Token Type: access_id_ANYBODY 323 Defining Authority: none 324 Value: none 326 Token Type: access_id_HOST 327 Defining Authority: IPaddress 328 Value: 164.67.21.82 330 Token Type: access_id_GROUP 331 Defining Authority: DCE 332 Value: 15 334 Token Type: access_id_CA 335 Defining Authority: X.509 336 Value: /C=US/O=Globus/CN=Globus CA 338 Token Type: access_id_APPLICATION 339 Defining Authority: checksum 340 Value: 123x56 342 6.2. Grantor identity 344 The grantor identity represents an identity used to specify the 345 grantor of a capability or a delegated credential. Its structure is 346 similar to the one of the access identity described in the previous 347 subsection. 349 Example: 351 Token Type: grantor_id_USER 352 Defining Authority: kerberos.V5 353 Value: kot@ISI.EDU 355 6.3. Access rights 357 It must be possible to specify which principals or groups of principals are 358 authorized for specific operations, as well as who is explicitly 359 denied authorizations, therefore we define positive and negative access 360 rights. 362 All operations defined on the object are grouped by type of access to 363 the object they represent, and named using a tag. 364 For example, for a file the following operations are defined: 366 Token Type: pos_access_rights 367 Defining Authority: local_manager 368 Value: FILE:read,write,execute 370 However, in a bank application, an object might also be a customer 371 account, and the following set of operation might be defined: 373 Token Type: pos_access_rights 374 Defining Authority: local_manager 375 Value: ACCOUNT:deposit,withdraw,transfer 377 Internally a tagged bit vector represents access rights. 378 Each bit in the vector corresponds to an access right. 379 The tag indicates how the bits in the bit vector are to be interpreted, 380 in the example above, for the set of rights associated with the tag FILE the 381 first bit should be interpreted as read, while for the set 382 associated with tag ACCOUNT, the same bit should be interpreted as 383 deposit. 385 6.4. Conditions 387 The conditions specify the type-specific policies under which an 388 operation can be performed on an object. 390 Conditions can be categorized as generic or specific. A condition 391 is generic if it is evaluated by the access control model. Specific 392 conditions are application-dependent and usually evaluated by the 393 application. 394 Conditions are evaluated recursively. Recursive evaluation of 395 conditions is done not through recursive GAA-API calls, but though a 396 recursive evaluation within the GAA-API. 398 6.4.1. Generic conditions 400 The following list of generic conditions should not be considered 401 exhaustive. 403 a) time 405 Time periods for which access is granted, e.g. time of day or 406 day of the week 408 b) location 410 Location of the principal. Authorization is granted to the 411 principals residing in specific hosts or domains. 413 c) connection 415 c.1. security of the connection 417 1) required confidentiality message protection 418 This condition specifies a mechanism, or a set of 419 mechanisms to be used in confidentiality message protection. 421 2) required integrity message protection 422 This condition specifies a mechanism, or a set of 423 mechanisms to be used in integrity message protection. 425 c.2. bandwidth 427 c.3. particular network (SAN vs. LAN for a cluster) 429 c.4. dialup 431 d) privilege constraints 433 In general, a principal may belong to more than one group. 434 By default, principal operates with the union of privileges of 435 all groups to which it belongs, as well as all of his individual 436 privileges. 437 In assigning privileges, one can choose to: 439 1) have the subject operate with the privilege of only one group 440 at a time. This can be used to reduce privileges as a 441 protection against accidents. 442 E.g. a person is a member of two groups: PROGRAMMERS and 443 SYSTEM_MANAGERS. The person may act with the privileges of the 444 group PROGRAMMERS most of the time, and enable privileges of 445 the SYSTEM_MANAGERS group only on occasion. 447 2) have the subject operate with privileges of several specified 448 groups at a time. This condition class allows one to express 449 "group A and group B" 451 3) endorsement 452 Concurrence of several principals to perform some operation. 454 e) multi-level security constraints 456 f) payment 458 Specifies currency and amount that must be paid prior 459 access to an object will be granted. 461 g) quota 463 Specifies a currency and a limit. It limits the quantity of a resource 464 that can be consumed or obtained. 466 h) strength of authentication 468 Specifies the authentication mechanism or a set of suitable 469 mechanisms, used to authenticate a user. 471 i) attributes of subjects 473 This class of conditions defines a set of attributes that must be 474 possessed by subjects in order to get access to the object, e.g. 475 security label. 477 j) trust constrains 479 This class of conditions specify constraints on legitimacy of 480 the received certificate chain and the authenticity of the 481 specified keys: 483 1) Constraints placed in the certificates by CA when issuing 484 a certificate. They are represented as a list of certificate 485 extensions and marked as critical/non-critical. For example, 486 the extension may contain policy specifying that no further 487 delegation of CA authority is allowed. 489 2) Specify trustworthiness of CA to sign certificates for limited 490 set of users. 492 3) Restrictions on certification path: 494 a) Permitted and denied subtrees of CA authorities. 496 b) Limit the length of certificate chains (depth of the subtree). 498 4) Restrictions imposed on cryptographic attributes: 499 - accepted signature scheme (e.g. DSA/SHA, RSA/MD2) 500 - minimum public key length (768, 1024 bits) 502 5) Deciding to trust particular end-entity certificate for 503 particular purpose (operation). 505 k) audit information 507 Auditing access to protected objects such as files, print queue that is handing sensitive 508 documents or a terminal to catch attempted password grabbers, has to be selective since 509 access requests can occur frequently. 511 Audit condition enables generating audit records in response to access requests to protected 512 objects. This condition may specify: 514 a) When to log: 515 - success or failure (or both) of the request 516 - monitor particular user's behavior 517 - logging in from a number of terminals 518 - logging in at unusual times of the day or the week 520 b) Where to log: write audit information to operator terminal or audit log 522 6.4.2. Application-specific conditions 524 If generic conditions are not sufficient for expressing 525 application-specific security policies, applications specify their 526 own conditions. 527 Anything that can be expressed as type : value alphanumeric string can 528 be a condition. The application must provide a means for evaluation 529 of the application-specific conditions. 531 Token Type: printer_load 532 Defining Authority: PrinterManager 533 Value: 10 535 7. Capabilities and ACLs 537 Proposed security attributes allow to implement both capabilities 538 and ACLs. For example, the following sequence of security attributes 539 implements an ACL, stating that anyone authenticated by Kerberos.V5 540 has read access to the targeted object and any member of 541 group 15 connecting from the USC.EDU domain has read and write 542 access to the object. 544 Token Type: access_id_ANYBODY 545 Defining Authority: none 546 Value: none 548 Token Type: pos_access_rights 549 Defining Authority: local_manager 550 Value: FILE:read 552 Token Type: authentication_mechanism 553 Defining Authority: system_manager 554 Value: kerberos.V5 556 Token Type: access_id_GROUP 557 Defining Authority: DCE 558 Value: 15 560 Token Type: pos_access_rights 561 Defining Authority: local_manager 562 Value: FILE:read,write 564 Token Type: location 565 Defining Authority: system_manager 566 Value: *.USC.EDU 568 The following sequence of security attributes implements 569 a capability, stating that the capability granted by the group "admin" 570 grants read access if the capability is presented during the specified 571 time period. 573 Token Type: grantor_id_GROUP 574 Defining Authority: kerberos.V5 575 Value: admin@USC.EDU 577 Token Type: pos_access_rights 578 Defining Authority: local_manager 579 Value: FILE:read 581 Token Type: time_window 582 Defining Authority: eastern_timezone 583 Value: 8:00AM-5:00PM 585 8. Ordering Issues 587 The order in which security attributes are appearing is very important 588 for correctly interpreting the intended security policy. 589 It is not clear if interpretation of security attribute ordering should 590 be included in the draft or left as an implementation issue. 592 9. Inheritance 594 Underlying systems may use inheritance, for example the Netware security 595 model propagates inheritance rights down the directory tree, so that there 596 is not a single ACL to evaluate. In NT one can get access to an file either 597 through the directory or through the file itself, so again there are two 598 ACLs. 599 Inheritance can be supported in the function one provides to obtain 600 the ACL (see section 11), i.e. it needs to look at the object name and 601 determine which sources (possibly multiple sources) to draw ACL entries 602 from. 603 It might also add entries that refer to other named ACLs that would be 604 "included" in the primary ACL or interpreted at other points. How 605 this should work is something that is open for definition/discussion 606 with those needing this feature. 608 10. Security context 610 The security context is a GAA-API data structure, which is passed as 611 an argument to the GAA-API. 612 It stores information relevant to access control policy, e.g. 613 authentication and authorization credentials presented or used by the 614 peer entity (usually the client of the request), connection state 615 information. 617 The context consists of: 619 1) Identity 621 Verified authentication information, such as principal name for a 622 particular security mechanism. 624 2) Authorized credentials 625 This type of credentials is used to hold delegated credentials and 626 capabilities. 628 3) Group membership 629 This type of credentials specifies that the grantee is a member of 630 only the listed groups. 632 4) Group non-membership 633 This type of credentials specifies that the grantee is NOT a member 634 of the listed groups. 636 5) Attributes 637 This type of credentials contains miscellaneous attributes 638 attached to the grantee, e.g. age of the grantee, grantee's security 639 clearance. 641 6) Unevaluated Credentials 642 Evaluation of the acquired credentials can be deferred till the 643 credential is needed to perform the operation. 645 7) Evaluation and Retrieval Functions for Upcalls 646 These functions are called to evaluate application-specific conditions, 647 to request additional credentials and verify them. 648 The GSS API is an example of how this can be filled in. 650 8) Connection State Information 651 Contains a mechanism-specific representation of per-connection 652 context, some of the data stored here include keyblocks, addresses. 654 11. Generic Authorization and Access API 656 The GAA-API is built into applications through a library. 657 It is used by applications to decide whether a subject 658 is authorized to perform particular operations on an object. In 659 this section we provide a brief description of the main GAA-API 660 routines. 662 11.1. GAA-API routines 664 1) gaa_initialize 666 The gaa_initialize must be called before any other GAA-API function. 667 It initializes the GAA-API structures and defines behavior of the gaa evaluation 668 routines. 670 Input: 672 o Pointer to the GAA-API structure 674 o Pointer to the implementation-specific structure 676 The implementation may require implementation-specific information to be passed and 677 returned during the GAA-API initialization. The structure of the passed and returned 678 information varies for different underlying implementations, which makes it difficult 679 to standardize the structure. 681 Output: 683 o Status code 685 2) gaa_cleanup 687 The gaa_cleanup cleans up internal GAA-API structures allocated and initialized 688 using the gaa_initialize function. The calling application should call gaa_cleanup 689 to free memory and internal implementation state before exiting. 691 Input: 693 o Pointer to the GAA-API structure 695 o Pointer to the implementation-specific structure 697 Output: 699 o Status code 701 3) gaa_get_object_policy_info 703 The gaa_get_object_policy_info function is called to obtain 704 security policy information associated with the object. In the 705 ACL-based systems, this information represents object ACLs, in 706 the capability-based systems, this information may contain a 707 list of authorities allowed to grant capabilities. 709 Input: 711 o Reference to the object to be accessed. 713 The identifier for the object is from an application-dependent name 714 space, it can be represented as unique object identifier, or symbolic 715 name local to the application. 717 o Reference to an application-specific authorization database. 719 Output: 721 o Status code 723 o A handle to a structure, containing the security policy associated with 724 the targeted object. 726 4) gaa_check_authorization 728 The gaa_check_authorization function tells the application 729 server whether the requested operation or a set of operations 730 is authorized, or if additional checks are required. 732 Input: 734 o Pointer to the GAA-API structure. 736 o A handle to a policy structure, returned by the gaa_get_object_policy_info. 738 o Principal's security context. 740 o A list of access rights for authorization. 742 o GAA-API options structure (optional) 743 This argument contains parameters for parameterized 744 operation (see section 13). 746 Output: 748 o Status code: 750 YES code (indicating authorization) is returned if all requested 751 operations are authorized. 753 NO code (indicating denial of authorization) is returned if at 754 least one operation is not authorized. 756 MAYBE code (indicating a need for additional checks) is returned 757 if there are some unevaluated conditions and additional 758 application-specific checks are needed, or continuous 759 evaluation is required. 761 o Detailed answer. 763 Detailed answer contains: 765 o Authorization valid time period. 766 The time period during which the authorization is granted is 767 returned as condition to be checked by the application. 768 Expiration time is calculated based on time-related restrictions 769 expressed by the security attributes and restrictions in the 770 authentication, authorization and delegated credentials. 772 o The requested operations are returned marked as granted or denied 773 along with a list of corresponding conditions, if any. 774 Each condition is marked as evaluated or not evaluated, if 775 evaluated marked as met, not met or further evaluation or 776 enforcement is required. This tells application which policies 777 must be enforced. 779 o Information about additional security attributes required. 780 Additional credentials might be required from clients to 781 perform certain operations, e.g. group membership or delegated 782 credentials. 783 The application must understand the conditions that are returned 784 unevaluated or it must reject the request. 785 If understood, the application checks the conditions against 786 information about the request, the target object, or environmental 787 conditions to determine whether the conditions are met. Enforcement 788 of the returned conditions is up to the application. 790 5) gaa_inquire_policy_info 792 The gaa_inquire_object_policy_info function allows application 793 to discover a particular user's rights on an object. It returns a 794 list of rights that the principal is authorized for and corresponding 795 conditions, if any. 797 Input: 799 o Pointer to the GAA-API structure. 801 o A handle to a policy structure, returned by the gaa_get_object_policy_info. 803 o Principal's security context. 805 Output: 807 o Status code. 809 o A list of authorized and denied rights and corresponding conditions, 810 if any. 812 12. Creation of the GAA-API security context 814 Prior to calling the gaa_check_authorization function, the application 815 must obtain the authenticated principal's identity and store it in the 816 security 817 context. This context may be constructed from credentials obtained from 818 different mechanisms, e.g. GSS API, Kerberos or others. 819 This scenario places a heavy burden on the application programmer 820 to provide the integration of the security mechanism with the 821 application. A second scenario is to obtain the authentication 822 credentials from a transport protocol that already has the 823 security context integrated with it. For example, the application can call 824 SSL or authenticated RPC. In this case, it is the implementation of the 825 transport mechanism (usually written by someone other than the application 826 programmer) which calls the security API requesting principal's identity, 827 and which constructs the security context. 829 The principal's authentication information is placed into the 830 security context and is passed to the GAA-API. When additional security 831 attributes are required for the requested operation, the list of 832 required attributes is returned to be obtained by the application. The 833 application may provide GAA-API with an upcall function for 834 requesting required additional credentials. 836 The credentials pulled by the GAA-API are verified and added to 837 the security context by the upcall function. A reference to the 838 upcall function is passed to the GAA-API as part of the security 839 context, and it added to the security context by the application or 840 transport. 842 13. Parameterized operation 844 Some operations for authorization may require parameters. For example, 845 request to transfer $20 will be expressed as operation: transfer 846 parameter: amount:$20. 847 Parameters are different from conditions and one can not merge lists 848 of each. Parameters must be typed to describe what they mean, and that 849 condition evaluation functions that check parameters must define the 850 types of the parameters that they check: if it of a single type and what 851 type it is, or if it is a structure, and if it is a structure, what 852 each of the elements in the structure is. 853 When evaluating conditions that need to see parameters 854 they would then use the GAA options structure and interpret the parameter 855 and match each "variable" with the particular parameter they are looking for. 856 Data in the GAA options structure is used to pass parameters. 858 14. Credential evaluation 860 Credentials are translated to the GAA-API internal format and 861 placed into the GAA-API security context. 862 When evaluating a policy, e.g., ACL, the necessary credentials 863 are looked for in the security context. 865 ACL entries containing principals that do not match the current 866 subject identity but grant the requested operation and the identities 867 that are associated with the subject, stored in the security 868 context, e.g. group memberships and delegated credentials, are taken 869 into account when evaluating an ACL. 871 In general, when an ACL grants requested operation and no additional 872 credentials are required, the GAA-API will look for credentials that can 873 cause denial. A principal may chose to withhold credentials that it believes 874 may result in a denial. 875 There may be interactions when independent credentials are used, i.e., 876 one set of credentials causes denial, but the other causes accept. 877 Administrator has to deal with these issues by carefully setting 878 policies in an ACL. It may be appropriate to specify more restricted 879 set of rights and require grant credentials to be presented. 880 A condition may specify whether grant or denial credentials take 881 precedence. 883 15. Extended example: simple Printer Manager application 885 To illustrate how the GAA-API is used by application servers we 886 describe a simple Printer Manager application, where protected objects 887 are printers. The Printer Manager accepts requests from users to access 888 printers and invokes the GAA-API routines to make authorization 889 decisions, under the assumption that the administrator of the resources 890 has specified the local policy regarding the use of the resources by 891 means of ACL files. 892 These files are stored in an Authorization Database, maintained by the 893 Printer Manager. 895 15.1 Conditions 897 Administrators will be more willing to grant access to the 898 printers if they can restrict the access to the resources to users or 899 organizations they trust. Further, the administrators should be 900 able to specify time availability, restrictions on resources consumed 901 by the clients and accounting for the consumed resources. To 902 specify these limits, the Printer Manager uses generic conditions, such as 903 time, location, payment and quota. 905 An example of Printer Manager-specific condition: printer load, expressed 906 as maximum number of jobs that allowed to be submitted to a printer. 908 15.2 Authorization walk-through 910 Here we present an authorization scenario to demonstrate the use of 911 the authorization framework for the case of printing a document. 912 Assume Kerberos V5 is used for principal authentication. Assume that 913 printer A has an ACL stored in the Printer Manager authorization database. 915 Let's consider a request from user Tom who is connecting from the 916 ORG.EDU domain to print a document on the printer A at 7:30 PM. 918 When a client process running on behalf of the user "Tom" contacts the 919 Printer Manager with the request to submit_print_job (which 920 is indicated by setting the appropriate bit in the bit vector) to 921 printer A, the Printer Manager first calls gaa_initialize function 922 to allocate GAA-API internal structures and initialize the specific 923 GAA-API state. Then the Printer Manager calls the gaa_get_object_policy_info 924 function to obtain a sequence of security attributes representing the 925 security policy expressed in the ACL for the printer A. The upcall 926 function for retrieving the sequence is passed to the GAA-API and is 927 being called by the gaa_get_object_policy_info, which returns the 928 sequence. 929 Assume that the following sequence was returned: 931 ----------------------------------------- first EACL entry 933 Token Type: access_id_USER 934 Defining Authority: kerberos.V5 935 Value: tom@ORG.EDU 937 Token Type: pos_access_rights 938 Defining Authority: PrinterManager 939 Value: PRINTER:submit_print_job 941 Token Type: time_window 942 Defining Authority: pacific_time_zone 943 Value: 8:00AM-8:00PM 945 Token Type: printer_load 946 Defining Authority: PrinterManager 947 Value: 20 949 ----------------------------------------- second EACL entry 951 Token Type: pos_access_id_ANYBODY 952 Defining Authority: none 953 Value: none 955 Token Type: pos_access rights 956 Defining Authority: PrinterManager 957 Value: PRINTER:view_printer_capabilities 959 The Printer Manager must place the principal's authenticated identity in 960 the security context to pass it to the gaa_check_authorization function. 961 This context may be constructed according to the first or second 962 scenario, described in section 12. 963 If Tom is authenticated successfully, then verified identity credentials 964 are placed into the security context, specifying Tom as the Kerberos 965 principal tom@ORG.EDU. 967 Then the Printer Manager calls the gaa_check_authorization function. 968 In evaluating the security attribute sequence. The set, corresponding 969 to the first entry applies. It grants the requested operation, but there 970 two conditions that must be evaluated. 972 The first condition time_window : 8AM-8PM is generic and is evaluated 973 directly by the GAA-API. Since, the request was issued at 7:30 PM 974 this condition is satisfied. 975 The second condition printer_load : 20 is specific. 976 If the security context defined a condition evaluation function for 977 upcall, then this function is invoked and if this condition is met then 978 the final answer is YES (authorized) and the detailed answer contains: 979 Authorization expiration time : 8PM (assume that authentication 980 credential has expiration time 9PM). 982 Allowed operations: submit_print_job 983 List of conditions: time_window : 8AM-8PM 984 printer_load : 20 986 Both conditions are marked as evaluated and met. 988 During the execution of the task the Printer Manager is enforcing 989 the limits imposed on the local resources and authorization time. 991 If the corresponding upcall function was not passed to the GAA 992 API, the answer is MAYBE and the second condition is marked as 993 not evaluated and must be checked by the Printer Manager. 995 When additional credential is needed, then if the security context 996 defines a credential retrieval function for upcall, then this function 997 is invoked. If the requested credential is obtained, then the final 998 answer is YES. If the upcall function was not passed to the GAA-API, 999 the answer is NO. Before the Printer Manager exits, it calls 1000 gaa_cleanup to free allocated memory and other internal GAA-API state. 1002 16. Integration with existing authentication mechanisms 1004 The framework supports various strengths of user authentication 1005 mechanisms. An ACL may have entries associated with different 1006 principals identifying the same subject using different authentication 1007 methods. 1008 A subject may be granted a different set of rights, depending on 1009 the strength of the authentication method used for identification. 1010 Specification of weaker authentication methods including network 1011 address or username will allow the GAA-API to be used with any 1012 existing application that does not have support for strong 1013 authentication. 1015 17. Integration with existing authorization mechanisms 1017 Existing tools and ACLs stored by the underlying system should be 1018 usable in some sense - perhaps through a converter. 1020 18. Integration with alternative authorization models 1022 The proposed framework can be easily integrated with existing 1023 access control models in a uniform and consistent manner. 1024 [7] shows how this mechanism can implement role-based access control, 1025 Clark-Wilson model and lattice-based policies. 1027 19. References 1029 [1] B.C. Neuman. 1030 Proxy-based authorization and accounting for distributed systems. 1031 Proceedings of the 13th International Conference on Distributed 1032 Computing Systems, Pittsburgh, May 1993. 1034 [2] B.C. Neuman and Theodore Ts'o. 1035 Kerberos: An authentication service for computer networks. 1036 IEEE Communications Magazine, pages 33-38, September 1994 1038 [3] M. Blaze, J. Feigenbaum and J. Lacy. 1039 Decentralized Trust Management. 1040 in Proc. IEEE Symp. on Security and Privacy, IEEE Computer Press, 1041 Los Angeles, pages 164-173, 1996. 1043 [4] Large Scale Multicast Applications (lsma) working group. 1044 Taxonomy of Communication Requirements for Large-scale Multicast 1045 Applications. 1046 Internet draft. 1048 [5] Department of Defense National Computer Security Center. 1049 Department of Defense Trusted Computer system Evaluation Criteria, 1050 December 1985. DoD 5200.28-STD 1052 [6] Tom Parker and Denis Pinkas. 1053 Extended Generic Security Service APIs: XGSS-APIs Access control and 1054 delegation extensions 1055 Internet-Draft IETF Common Authentication Technology WG 1057 [7] T.V. Ryutov and B.C. Neuman 1058 An Authorization Framework for Distributed Systems 1059 Paper was submitted for the NDSS'2000. 1060 http://gost.isi.edu/info/gaa_api.html 1062 20. Acknowledgments 1064 Carl Kesselman, Mike Swift, Denis Pinkas, Gene Tsudik, Brian Tung, 1065 Bapa Rao, Ilia Ovsiannikov and the Xerox IS team have contributed 1066 to discussion of ideas and material in this draft. 1068 21. Authors' Addresses 1070 Tatyana Ryutov 1071 Clifford Neuman 1072 USC/Information Sciences Institute 1073 4676 Admiralty Way Suite 1001 1074 Marina del Rey, CA 90292-6695 1075 Phone: +1 310 822 1511 1076 E-Mail: {tryutov, bcn}@isi.edu