idnits 2.17.1 draft-ietf-cat-acc-cntrl-frmw-03.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 1040 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 28 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 168 has weird spacing: '...allowed if ce...' == Line 342 has weird spacing: '...ty used to sp...' == Line 635 has weird spacing: '...ontains misce...' == Line 686 has weird spacing: '...ence of secur...' == Line 784 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 (March 9, 2000) is 8813 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 989, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 993, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1003, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1007, 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 September 2000 USC/Information Sciences Institute 4 draft-ietf-cat-acc-cntrl-frmw-03.txt March 9, 2000 6 0. Status Of this Document 8 This document is an Internet-Draft and is in full conformance 9 with all provisions of Section 10 of RFC2026. 11 Internet-Drafts are working documents of the Internet Engineering 12 Task Force (IETF), its areas, and its working groups. Note that 13 other groups may also distribute working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet-Drafts 18 as reference material or to cite them other than as 19 "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 To view the entire list of current Internet-Drafts, please check 28 the "1id-abstracts.txt" listing contained in the Internet-Drafts 29 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 30 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 31 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 32 (US West Coast). 34 1. Abstract 36 This document describes a unified model to support authorization in a 37 wide range of applications, including metacomputing, remote printing, 38 video conference, and any other application which will require 39 interactions between entities across autonomous security domains. 41 The document proposes requirements for the support of: 43 - flexible and expressive mechanism for representing 44 and evaluating security policies 46 - uniform authorization service interface for facilitating access 47 control decisions for applications and requesting access control 48 information about a particular resource. 50 This specification defines structures and their uses at a level 51 independent of underlying mechanism and programming language environment. 52 This document is accompanied by a second one describing the details of 53 proposed structures and services along with bindings for C language 54 environments. This document is to be found in 55 draft-ietf-cat-gaa-cbind-03.txt. 57 2. Introduction 59 The variety of services available on the Internet continues to increase 60 and new classes of applications such as metacomputing, remote printing, 61 video conference is evolving. These applications will require 62 interactions between entities across autonomous security domains. 64 The distributed nature of the system, consisting of mutually suspicious 65 security domains, requires a mechanism, which provides fine-grained 66 access control to resources. 68 For example, access control requirements of a remote printing application 69 may include: 71 - authorized individual users and organizations 72 - time availability, e.g. time of the day or day of the week 73 - restrictions on resources consumed by the clients, e.g. maximum 74 job size, maximum number of pages per job 75 - required confidentiality/integrity message protection 76 - accounting for consumed resources 78 Access control requirements of large-scale multicast application [4], 79 e.g. corporate video conference may include: 81 - authorized individual users and organizations 82 - host properties; users on slow hosts or hosts running the wrong 83 OS will be denied communication 84 - accounting for consumed resources 86 Some of the security requirements are common across different 87 applications, while others are more individual. 89 Access control policies can be formulated in many ways. Administrators 90 Of each domain might use domain-specific policy syntax and 91 heterogeneous implementations of the policies. 93 It is necessary to define a particular framework applicable for 94 a wide range of systems and applications, which will allow to discuss 95 specific requirements for the representation and evaluation of security 96 policies. 97 An application developer should not have to give anything up by using 98 this framework, therefore the framework should provide support for 99 integration with existing OS or toolkit provided access control 100 mechanisms. 101 High-speed implementations should be provided for operations that are 102 supported natively by the underlying system. 104 The focus of this framework is based on the following two abstractions: 106 1) uniform mechanism for representation and evaluation of security 107 policies 109 It should be capable of implementing a number of different security 110 policies, based on diverse authorization models, which can coexist in 111 distributed system. Standardizing the way that applications define their 112 security requirements provides the means for integration of local and 113 distributed security policies and translation of security policies 114 across multiple authorization models. 116 The mechanism should support the common authorization requirements but 117 provide the means to defining and integration with application or 118 organization specific policies as well. Applications should not need to 119 re-implement the basic authorization functions in an 120 application-specific manner. 122 2) Generic Authorization and Access control Application Program 123 Interface (GAA API) 125 A common API will facilitate authorization decisions for applications. 126 An application invokes the API functions to determine if a requested 127 operation or set of operation are authorized or if additional checks 128 are necessary. 130 The API will support the needs of most applications, thus not forcing 131 the developers to design their own authorization mechanisms. 132 The API will allow better integration of multiple mechanisms with 133 application servers. The GSS API can be used by the GAA API to 134 obtain principal's identity see section 11. 136 Section 12 gives an extended example how the GAA API can be used by 137 applications. 139 3. Glossary 141 OBJECT (RESOURCE) 142 entity that has to be protected e.g. hosts, files. 144 SUBJECT 145 entity that can initiate requests to an object e.g. individual users, 146 hosts, applications and groups. 148 PRINCIPAL 149 identity associated with a subject as a result of some unspecified 150 authentication protocol. It can refer to a person, group, host, and 151 application. Several principals can be associated with the same 152 subject. 154 SECURITY POLICY 155 the set of rules that govern access to objects 157 ACCESS RIGHT (OPERATION, PERMISSION) 158 a particular type of access to a protected object e.g. read, write, 159 and execute 161 RESTRICTION (CONDITION) 162 a specific policy allowing an operation to be performed on an 163 object 165 This policy can have two meanings: 167 1) descriptive 168 An operation is allowed if certain condition is satisfied. 169 For instance, a policy may require concurrence of two 170 principals to perform some operation. If participation of 171 both principals can be proved then this policy is satisfied. 173 2) prescriptive 174 An operation will be allowed if certain restrictive policy 175 is enforced. 177 For example, a process will be authorized to run on a host 178 if the memory usage limits that a process can occupy in main 179 memory satisfies certain constraints. Continuous evaluation of 180 restriction is required. 182 DELEGATION 183 is the ability of a principal to give to another principal limited 184 authority to act on its behalf. 186 CREDENTIAL 187 a statement of identity, group membership and non-membership, 188 privilege attribute and transfer of privilege encoded in 189 certificates. 191 4. Architecture 193 The major components of the architecture are: 195 Authentication mechanisms (perhaps involving an authentication 196 server) perform authentication of users and supply them with 197 initial credentials. 199 A group server is trusted to maintain and provide group membership 200 information. A group is a convenient method to associate a name with 201 a set of principals for access control purposes. A group server issues 202 group membership and non-membership certificates. When a connection is 203 established with an application server, these certificates are evaluated 204 (evaluation may be deferred until needed) the results are placed into 205 the GAA API security context. They are checked by the GAA API when 206 making authorization decisions. 208 The application calls the GAA API routines to check authorization 209 against the application authorization model. 210 These routines obtain access control information from local 211 files, distributed authorization servers, and from credentials 212 provided by the user, combining local and distributed authorizations 213 under a single API according to the requirements of the application. 215 Delegation is supported through inclusion of delegated credentials. 216 Mechanism for delegation such as those supported by 217 restricted proxies [1] in the security context, where they are 218 available for use by authentication and authorization mechanisms 219 used for subsequent connections from the server (now acting as an 220 intermediary) to another server. 222 5. Objects 224 The purpose of access control is protecting objects from unauthorized 225 access. The kinds of objects to be protected are specific to the 226 application to which the authorization model is applied and are not 227 included into the authorization model. 228 The objects that need to be protected include files, directories, 229 network connections, hosts, auxiliary devices, e.g. printers and 230 faxes, and other entities. An authorization mechanism should support these 231 different kinds of objects in a uniform manner. Same security attribute 232 structure should be used to specify access policies for different kinds of 233 objects. 234 Object names should be drawn from the application-specific name space 235 and must be opaque to the authorization mechanism. 237 6. Security policy representation 239 One may think about the security policy associated with a protected 240 resource as a set of operations which a defined set of principals 241 is allowed to perform on the target resource, and optional constraints 242 placed on the granted operations. For example, a system administrator 243 can define the following security policy to govern access to a 244 printer: "Joe Smith and members of Department1 are allowed to print 245 documents Monday through Friday, from 9:00AM to 6:00PM". 246 This policy can be described by an ACL mechanism, where for each 247 resource, a list of valid entities is granted a set of access rights. 248 The same policy can be implemented using a capability mechanism. 249 However, traditional ACL and capability abstractions should be 250 extended to allow conditional restrictions on access rights. 252 Therefore, in implementing a policy, it should be possible to 253 define: 254 1) access identity 255 2) grantor identity 256 3) a set of access rights 257 4) a set of conditions 259 Policy is represented by a sequence of tokens. Each token consists of: 261 Token Type 263 Defines the type of the attribute. Tokens of the same type 264 have the same authorization semantics. 266 Defining Authority 268 It indicates the authority responsible for defining the value 269 within the attribute type. 271 Value 273 The value of the security attribute. Its syntax is determined by 274 the attribute type. The name space for the value is defined by 275 the Defining Authority field 277 6.1. Access identity 279 The access identity represents an identity to be used for access 280 control purposes. The authorization framework should support the 281 following kinds of access identity: 283 1) USER 284 identifies a person, e.g. authenticated user name. 286 2) HOST 287 identifies a subject as a machine from which request to access 288 the object was originated, e.g., an IP address or host DNS name 289 or host public key. 291 3) APPLICATION 292 identifies a certain program that has its own associated identity 293 (principal),e.g., a checksum or certified name. 294 This can be useful to grant access to a certain application, 295 e.g. payment program, that is trusted to be written correctly and 296 perform only its intended purpose. 298 4) CA 299 identifies a Certification Authority responsible for issuing a 300 certificate. 302 5) GROUP 303 identifies a group of subjects. The kind of subjects 304 (individual user, host or application) composing the group is 305 opaque to the authorization mechanism. 307 6) ANYBODY 308 represents any subject regardless of authentication. 309 This may be useful for setting the default policies. 311 The framework should support multiple existing principal naming 312 methods. Different administrative domains might use different 313 authentication mechanisms, each having a particular syntax for 314 specification of principals. Therefore, Defining Authority for access 315 identity indicates underlying authentication mechanism used to provide 316 the principal identity. Value represents particular principal identity. 318 Examples of access identities are: 320 Token Type: access_id_ANYBODY 321 Defining Authority: none 322 Value: none 324 Token Type: access_id_HOST 325 Defining Authority: IPaddress 326 Value: 164.67.21.82 328 Token Type: access_id_GROUP 329 Defining Authority: DCE 330 Value: 15 332 Token Type: access_id_CA 333 Defining Authority: X.509 334 Value: /C=US/O=Globus/CN=Globus CA 336 Token Type: access_id_APPLICATION 337 Defining Authority: checksum 338 Value: 123x56 340 6.2. Grantor identity 342 The grantor identity represents an identity used to specify the 343 grantor of a capability or a delegated credential. Its structure is 344 similar to the one of the access identity described in the previous 345 subsection. 347 Example: 349 Token Type: grantor_id_USER 350 Defining Authority: kerberos.V5 351 Value: kot@ISI.EDU 353 6.3. Access rights 355 It must be possible to specify which principals or groups of principals are 356 authorized for specific operations, as well as who is explicitly 357 denied authorizations, therefore we define positive and negative access 358 rights. 360 All operations defined on the object are grouped by type of access to 361 the object they represent, and named using a tag. 362 For example, for a file the following operations are defined: 364 Token Type: pos_access_rights 365 Defining Authority: local_manager 366 Value: FILE:read,write,execute 368 However, in a bank application, an object might also be a customer 369 account, and the following set of operation might be defined: 371 Token Type: pos_access_rights 372 Defining Authority: local_manager 373 Value: ACCOUNT:deposit,withdraw,transfer 375 Internally a tagged bit vector represents access rights. 376 Each bit in the vector corresponds to an access right. 377 The tag indicates how the bits in the bit vector are to be interpreted, 378 in the example above, for the set of rights associated with the tag FILE the 379 first bit should be interpreted as read, while for the set 380 associated with tag ACCOUNT, the same bit should be interpreted as 381 deposit. 383 6.4. Conditions 385 The conditions specify the type-specific policies under which an 386 operation can be performed on an object. 388 Conditions can be categorized as generic or specific. A condition 389 is generic if it is evaluated by the access control model. Specific 390 conditions are application-dependent and usually evaluated by the 391 application. 392 Conditions are evaluated recursively. Recursive evaluation of 393 conditions is done not through recursive GAA API calls, but though a 394 recursive evaluation within the GAA API. 396 6.4.1. Generic conditions 398 The following list of generic conditions should not be considered 399 exhaustive. 401 a) time 403 Time periods for which access is granted, e.g. time of day or 404 day of the week 406 b) location 408 Location of the principal. Authorization is granted to the 409 principals residing in specific hosts or domains. 411 c) connection 413 c.1. security of the connection 415 1) required confidentiality message protection 416 This condition specifies a mechanism, or a set of 417 mechanisms to be used in confidentiality message protection. 419 2) required integrity message protection 420 This condition specifies a mechanism, or a set of 421 mechanisms to be used in integrity message protection. 423 c.2. bandwidth 425 c.3. particular network (SAN vs. LAN for a cluster) 427 c.4. dialup 429 d) privilege constraints 431 In general, a principal may belong to more than one group. 432 By default, principal operates with the union of privileges of 433 all groups to which it belongs, as well as all of his individual 434 privileges. 435 In assigning privileges, one can choose to: 437 1) have the subject operate with the privilege of only one group 438 at a time. This can be used to reduce privileges as a 439 protection against accidents. 440 E.g. a person is a member of two groups: PROGRAMMERS and 441 SYSTEM_MANAGERS. The person may act with the privileges of the 442 group PROGRAMMERS most of the time, and enable privileges of 443 the SYSTEM_MANAGERS group only on occasion. 445 2) have the subject operate with privileges of several specified 446 groups at a time. This condition class allows one to express 447 "group A and group B" 449 3) endorsement 450 Concurrence of several principals to perform some operation. 452 e) multi-level security constraints 454 f) payment 456 Specifies currency and amount that must be paid prior 457 access to an object will be granted. 459 g) quota 461 Specifies a currency and a limit. It limits the quantity of a resource 462 that can be consumed or obtained. 464 h) strength of authentication 466 Specifies the authentication mechanism or a set of suitable 467 mechanisms, used to authenticate a user. 469 i) attributes of subjects 471 This class of conditions defines a set of attributes that must be 472 possessed by subjects in order to get access to the object, e.g. 473 security label. 475 j) trust constrains 477 This class of conditions specify constraints on legitimacy of 478 the received certificate chain and the authenticity of the 479 specified keys: 481 1) Constraints placed in the certificates by CA when issuing 482 a certificate. They are represented as a list of certificate 483 extensions and marked as critical/non-critical. For example, 484 the extension may contain policy specifying that no further 485 delegation of CA authority is allowed. 487 2) Specify trustworthiness of CA to sign certificates for limited 488 set of users. 490 3) Restrictions on certification path: 492 a) Permitted and denied subtrees of CA authorities. 494 b) Limit the length of certificate chains (depth of the subtree). 496 4) Restrictions imposed on cryptographic attributes: 497 - accepted signature scheme (e.g. DSA/SHA, RSA/MD2) 498 - minimum public key length (768, 1024 bits) 500 5) Deciding to trust particular end-entity certificate for 501 particular purpose (operation). 503 k) audit information 505 Auditing access to protected objects such as files, print queue that is handing sensitive 506 documents or a terminal to catch attempted password grabbers, has to be selective since 507 access requests can occur frequently. 509 Audit condition enables generating audit records in response to access requests to protected 510 objects. This condition may specify: 512 a) When to log: 513 - success or failure (or both) of the request 514 - monitor particular user's behavior 515 - logging in from a number of terminals 516 - logging in at unusual times of the day or the week 518 b) Where to log: write audit information to operator terminal or audit log 520 6.4.2. Application-specific conditions 522 If generic conditions are not sufficient for expressing 523 application-specific security policies, applications specify their 524 own conditions. 525 Anything that can be expressed as type : value alphanumeric string can 526 be a condition. The application must provide a means for evaluation 527 of the application-specific conditions. 529 Token Type: printer_load 530 Defining Authority: PrinterManager 531 Value: 10 533 7. Capabilities and ACLs 535 Proposed security attributes allow to implement both capabilities 536 and ACLs. For example, the following sequence of security attributes 537 implements an ACL, stating that anyone authenticated by Kerberos.V5 538 has read access to the targeted object and any member of 539 group 15 connecting from the USC.EDU domain has read and write 540 access to the object. 542 Token Type: access_id_ANYBODY 543 Defining Authority: none 544 Value: none 546 Token Type: pos_access_rights 547 Defining Authority: local_manager 548 Value: FILE:read 550 Token Type: authentication_mechanism 551 Defining Authority: system_manager 552 Value: kerberos.V5 554 Token Type: access_id_GROUP 555 Defining Authority: DCE 556 Value: 15 558 Token Type: pos_access_rights 559 Defining Authority: local_manager 560 Value: FILE:read,write 562 Token Type: location 563 Defining Authority: system_manager 564 Value: *.USC.EDU 566 The following sequence of security attributes implements 567 a capability, stating that the capability granted by the group "admin" 568 grants read access if the capability is presented during the specified 569 time period. 571 Token Type: grantor_id_GROUP 572 Defining Authority: kerberos.V5 573 Value: admin@USC.EDU 575 Token Type: pos_access_rights 576 Defining Authority: local_manager 577 Value: FILE:read 579 Token Type: time_window 580 Defining Authority: eastern_timezone 581 Value: 8:00AM-5:00PM 583 8. Ordering Issues 585 The order in which security attributes are appearing is very important 586 for correctly interpreting the intended security policy. 587 It is not clear if interpretation of security attribute ordering should 588 be included in the draft or left as an implementation issue. 590 9. Inheritance 592 Underlying systems may use inheritance, for example the Netware security 593 model propagates inheritance rights down the directory tree, so that there 594 is not a single ACL to evaluate. In NT one can get access to an file either 595 through the directory or through the file itself, so again there are two 596 ACLs. 597 Inheritance can be supported in the function one provides to obtain 598 the ACL (see section 11.1), i.e. it needs to look at the object name and 599 determine which sources (possibly multiple sources) to draw ACL entries 600 from. 601 It might also add entries that refer to other named ACLs that would be 602 "included" in the primary ACL or interpreted at other points. How 603 this should work is something that is open for definition/discussion 604 with those needing this feature. 606 10. Security context 608 The security context is a GAA API data structure, which is passed as 609 an argument to the GAA API. 610 It stores information relevant to access control policy, e.g. 611 authentication and authorization credentials presented or used by the 612 peer entity (usually the client of the request), connection state 613 information. 615 The context consists of: 617 1) Identity 619 Verified authentication information, such as principal name for a 620 particular security mechanism. 622 2) Authorized credentials 623 This type of credentials is used to hold delegated credentials and 624 capabilities. 626 3) Group membership 627 This type of credentials specifies that the grantee is a member of 628 only the listed groups. 630 4) Group non-membership 631 This type of credentials specifies that the grantee is NOT a member 632 of the listed groups. 634 5) Attributes 635 This type of credentials contains miscellaneous attributes 636 attached to the grantee, e.g. age of the grantee, grantee's security 637 clearance. 639 6) Unevaluated Credentials 640 Evaluation of the acquired credentials can be deferred till the 641 credential is needed to perform the operation. 643 7) Evaluation and Retrieval Functions for Upcalls 644 These functions are called to evaluate application-specific conditions, 645 to request additional credentials and verify them. 646 The GSS API is an example of how this can be filled in. 648 8) Connection State Information 649 Contains a mechanism-specific representation of per-connection 650 context, some of the data stored here include keyblocks, addresses. 652 11. Generic Authorization and Access API 654 The GAA API is built into applications through a library. 655 It is used by applications to decide whether a subject 656 is authorized to perform particular operations on an object. In 657 this section we provide a brief description of the main GAA API 658 routines. 660 11.1. GAA API functions 662 1) gaa_get_object_policy_info 664 The gaa_get_object_policy_info function is called to obtain 665 security policy information associated with the object. In the 666 ACL-based systems, this information represents object ACLs, in 667 the capability-based systems, this information may contain a 668 list of authorities allowed to grant capabilities. If no security 669 information is attached to the object, then this function can 670 be omitted. 672 Input: 674 o Reference to the object to be accessed 676 The identifier for the object is from an application-dependent name 677 space, it can be represented as unique object identifier, or symbolic 678 name local to the application. 680 o Pointer to the application-specific authorization database 682 Output: 684 o Mechanism-specific status code 686 o A handle to the sequence of security attributes which constitute 687 the security policy associated with the targeted object. 689 2) gaa_inquire_object_policy_info 691 The gaa_inquire_object_policy_info function allows application 692 to discover a particular user's rights on an object. It returns a 693 list of rights that the principal is authorized for and corresponding 694 conditions, if any. 696 Input: 698 o A handle to the sequence of security attributes, returned by 699 gaa_get_object_policy_info 701 o Principal's security context 703 Output: 705 o A list of authorized rights and corresponding conditions, if any, 706 is returned. 708 3) gaa_check_authorization 710 The gaa_check_authorization function tells the application 711 server whether the requested operation or a set of operations 712 is authorized, or if additional checks are required. 714 Input: 716 o A handle to the sequence of security attributes, returned by the 717 gaa_get_object_policy_info 719 o Principal's security context 721 o Operations for authorization 722 It indicates operations to be performed. 724 o GAA API options structure 725 This argument contains parameters for parameterized 726 operation (see section 13). 728 Output: 730 YES code (indicating authorization) is returned if all requested 731 operations are authorized. 733 NO code (indicating denial of authorization) is returned if at 734 least one operation is not authorized. 736 MAYBE code (indicating a need for additional checks) is returned 737 if there are some unevaluated conditions and additional 738 application-specific checks are needed, or continuous 739 evaluation is required. 741 o Mechanism-specific status code 743 o Detailed answer 745 Detailed answer contains: 747 o Authorization valid time period. 748 The time period during which the authorization is granted is 749 returned as condition to be checked by the application. 750 Expiration time is calculated based on time-related restrictions 751 expressed by the security attributes and restrictions in the 752 authentication, authorization and delegated credentials. 754 o The requested operations are returned marked as granted or denied 755 along with a list of corresponding conditions, if any. 756 Each condition is marked as evaluated or not evaluated, if 757 evaluated marked as met, not met or further evaluation or 758 enforcement is required. This tells application which policies 759 must be enforced. 761 o Information about additional security attributes required. 762 Additional credentials might be required from clients to 763 perform certain operations, e.g. group membership or delegated 764 credentials. 765 The application must understand the conditions that are returned 766 unevaluated or it must reject the request. 767 If understood, the application checks the conditions against 768 information about the request, the target object, or environmental 769 conditions to determine whether the conditions are met. Enforcement 770 of the returned conditions is up to the application. 772 12. Creation of the GAA API security context 774 Prior to calling the gaa_check_authorization function, the application 775 must obtain the authenticated principal's identity and store it in the 776 security 777 context. This context may be constructed from credentials obtained from 778 different mechanisms, e.g. GSS API, Kerberos or others. 779 This scenario places a heavy burden on the application programmer 780 to provide the integration of the security mechanism with the 781 application. A second scenario is to obtain the authentication 782 credentials from a transport protocol that already has the 783 security context integrated with it. For example, the application can call 784 SSL or authenticated RPC. In this case, it is the implementation of the 785 transport mechanism (usually written by someone other than the application 786 programmer) which calls the security API requesting principal's identity, 787 and which constructs the security context. 789 The principal's authentication information is placed into the 790 security context and is passed to the GAA API. When additional security 791 attributes are required for the requested operation, the list of 792 required attributes is returned to be obtained by the application. The 793 application may provide GAA API with an upcall function for 794 requesting required additional credentials. 796 The credentials pulled by the GAA API are verified and added to 797 the security context by the upcall function. A reference to the 798 upcall function is passed to the GAA API as part of the security 799 context, and it added to the security context by the application or 800 transport. 802 13. Parameterized operation 804 Some operations for authorization may require parameters. For example, 805 request to transfer $20 will be expressed as operation: transfer 806 parameter: amount:$20. 807 Parameters are different from conditions and one can not merge lists 808 of each. Parameters must be typed to describe what they mean, and that 809 condition evaluation functions that check parameters must define the 810 types of the parameters that they check: if it of a single type and what 811 type it is, or if it is a structure, and if it is a structure, what 812 each of the elements in the structure is. 813 When evaluating conditions that need to see parameters 814 they would then use the GAA options structure and interpret the parameter 815 and match each "variable" with the particular parameter they are looking for. 816 Data in the GAA options structure is used to pass parameters. 818 14. Credential evaluation 820 Credentials are translated to the GAA API internal format and 821 placed into the GAA API security context. 822 When evaluating a policy, e.g., ACL, the necessary credentials 823 are looked for in the security context. 825 ACL entries containing principals that do not match the current 826 subject identity but grant the requested operation and the identities 827 that are associated with the subject, stored in the security 828 context, e.g. group memberships and delegated credentials, are taken 829 into account when evaluating an ACL. 831 In general, when an ACL grants requested operation and no additional 832 credentials are required, the GAA API will look for credentials that can 833 cause denial. A principal may chose to withhold credentials that it believes 834 may result in a denial. 835 There may be interactions when independent credentials are used, i.e., 836 one set of credentials causes denial, but the other causes accept. 837 Administrator has to deal with these issues by carefully setting 838 policies in an ACL. It may be appropriate to specify more restricted 839 set of rights and require grant credentials to be presented. 840 A condition may specify whether grant or denial credentials take 841 precedence. 843 15. Extended example: simple Printer Manager application 845 To illustrate how the GAA API is used by application servers we 846 describe a simple Printer Manager application, where protected objects 847 are printers. The Printer Manager accepts requests from users to access 848 printers and invokes the GAA API routines to make authorization 849 decisions, under the assumption that the administrator of the resources 850 has specified the local policy regarding the use of the resources by 851 means of ACL files. 852 These files are stored in an Authorization Database, maintained by the 853 Printer Manager. 855 15.1 Conditions 857 Administrators will be more willing to grant access to the 858 printers if they can restrict the access to the resources to users or 859 organizations they trust. Further, the administrators should be 860 able to specify time availability, restrictions on resources consumed 861 by the clients and accounting for the consumed resources. To 862 specify these limits, the Printer Manager uses generic conditions, such as 863 time, location, payment and quota. 865 An example of Printer Manager-specific condition: printer load, expressed 866 as maximum number of jobs that allowed to be submitted to a printer. 868 15.2 Authorization walk-through 870 Here we present an authorization scenario to demonstrate the use of 871 the authorization framework for the case of printing a document. 872 Assume Kerberos V5 is used for principal authentication. Assume that 873 printer A has an ACL stored in the Printer Manager authorization database. 875 Let's consider a request from user Tom who is connecting from the 876 ORG.EDU domain to print a document on the printer A at 7:30 PM. 878 When a client process running on behalf of the user "Tom" contacts the 879 Printer Manager with the request to submit_print_job (which 880 is indicated by setting the appropriate bit in the bit vector) to 881 printer A, the Printer Manager first calls the gaa_get_object_policy_info 882 function to obtain a sequence of security attributes representing the 883 security policy expressed in the ACL for the printer A. The upcall 884 function for retrieving the sequence is passed to the GAA API and is 885 being called by the gaa_get_object_policy_info, which returns the 886 sequence. 887 Assume that the following sequence was returned: 889 ----------------------------------------- first EACL entry 891 Token Type: access_id_USER 892 Defining Authority: kerberos.V5 893 Value: tom@ORG.EDU 895 Token Type: pos_access_rights 896 Defining Authority: PrinterManager 897 Value: PRINTER:submit_print_job 899 Token Type: time_window 900 Defining Authority: pacific_time_zone 901 Value: 8:00AM-8:00PM 903 Token Type: printer_load 904 Defining Authority: PrinterManager 905 Value: 20 907 ----------------------------------------- second EACL entry 909 Token Type: pos_access_id_ANYBODY 910 Defining Authority: none 911 Value: none 913 Token Type: pos_access rights 914 Defining Authority: PrinterManager 915 Value: PRINTER:view_printer_capabilities 917 The Printer Manager must place the principal's authenticated identity in 918 the security context to pass it to the gaa_check_authorization function. 919 This context may be constructed according to the first or second 920 scenario, described in section 12. 921 If Tom is authenticated successfully, then verified identity credentials 922 are placed into the security context, specifying Tom as the Kerberos 923 principal tom@ORG.EDU. 925 Then the Printer Manager calls the gaa_check_authorization function. 926 In evaluating the security attribute sequence. The set, corresponding 927 to the first entry applies. It grants the requested operation, but there 928 two conditions that must be evaluated. 930 The first condition time_window : 8AM-8PM is generic and is evaluated 931 directly by the GAA API. Since, the request was issued at 7:30 PM 932 this condition is satisfied. 933 The second condition printer_load : 20 is specific. 934 If the security context defined a condition evaluation function for 935 upcall, then this function is invoked and if this condition is met then 936 the final answer is YES (authorized) and the detailed answer contains: 937 Authorization expiration time : 8PM (assume that authentication 938 credential has expiration time 9PM). 939 Allowed operations: submit_print_job 940 List of conditions: time_window : 8AM-8PM 941 printer_load : 20 942 Both conditions are marked as evaluated and met. 944 During the execution of the task the Printer Manager is enforcing 945 the limits imposed on the local resources and authorization time. 947 If the corresponding upcall function was not passed to the GAA 948 API, the answer is MAYBE and the second condition is marked as 949 not evaluated and must be checked by the Printer Manager. 951 When additional credential is needed, then if the security context 952 defines a credential retrieval function for upcall, then this function 953 is invoked. If the requested credential is obtained, then the final 954 answer is YES. If the upcall function was not passed to the GAA API, 955 the answer is NO. 957 16. Integration with existing authentication mechanisms 959 The framework supports various strengths of user authentication 960 mechanisms. An ACL may have entries associated with different 961 principals identifying the same subject using different authentication 962 methods. 963 A subject may be granted a different set of rights, depending on 964 the strength of the authentication method used for identification. 965 Specification of weaker authentication methods including network 966 address or username will allow the GAA API to be used with any 967 existing application that does not have support for strong 968 authentication. 970 17. Integration with existing authorization mechanisms 972 Existing tools and ACLs stored by the underlying system should be 973 usable in some sense - perhaps through a converter. 975 18. Integration with alternative authorization models 977 The proposed framework can be easily integrated with existing 978 access control models in a uniform and consistent manner. 979 [7] shows how this mechanism can implement role-based access control, 980 Clark-Wilson model and lattice-based policies. 982 19. References 984 [1] B.C. Neuman. 985 Proxy-based authorization and accounting for distributed systems. 986 Proceedings of the 13th International Conference on Distributed 987 Computing Systems, Pittsburgh, May 1993. 989 [2] B.C. Neuman and Theodore Ts'o. 990 Kerberos: An authentication service for computer networks. 991 IEEE Communications Magazine, pages 33-38, September 1994 993 [3] M. Blaze, J. Feigenbaum and J. Lacy. 994 Decentralized Trust Management. 995 in Proc. IEEE Symp. on Security and Privacy, IEEE Computer Press, 996 Los Angeles, pages 164-173, 1996. 998 [4] Large Scale Multicast Applications (lsma) working group. 999 Taxonomy of Communication Requirements for Large-scale Multicast 1000 Applications. 1001 Internet draft. 1003 [5] Department of Defense National Computer Security Center. 1004 Department of Defense Trusted Computer system Evaluation Criteria, 1005 December 1985. DoD 5200.28-STD 1007 [6] Tom Parker and Denis Pinkas. 1008 Extended Generic Security Service APIs: XGSS-APIs Access control and 1009 delegation extensions 1010 Internet-Draft IETF Common Authentication Technology WG 1012 [7] T.V. Ryutov and B.C. Neuman 1013 An Authorization Framework for Distributed Systems 1014 Paper was submitted for the NDSS'2000. 1015 http://gost.isi.edu/info/gaa_api.html 1017 20. Acknowledgments 1019 Carl Kesselman, Mike Swift, Denis Pinkas, Gene Tsudik, Brian Tung, 1020 Bapa Rao, Ilia Ovsiannikov and the Xerox IS team have contributed 1021 to discussion of ideas and material in this draft. 1023 21. Authors' Addresses 1025 Tatyana Ryutov 1026 Clifford Neuman 1027 USC/Information Sciences Institute 1028 4676 Admiralty Way Suite 1001 1029 Marina del Rey, CA 90292-6695 1030 Phone: +1 310 822 1511 1031 E-Mail: {tryutov, bcn}@isi.edu