idnits 2.17.1 draft-ietf-aaa-authz-arch-00.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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 34 pages 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 724 has weird spacing: '...s, PIPs and P...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 1999) is 8959 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: '13' is defined on line 1355, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-16) exists of draft-ietf-policy-core-schema-03 -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-09) exists of draft-ietf-pkix-ac509prof-01 ** Obsolete normative reference: RFC 2459 (ref. '9') (Obsoleted by RFC 3280) ** Downref: Normative reference to an Informational RFC: RFC 2607 (ref. '10') ** Obsolete normative reference: RFC 2138 (ref. '11') (Obsoleted by RFC 2865) ** Obsolete normative reference: RFC 2002 (ref. '12') (Obsoleted by RFC 3220) ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. '13') Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT J. Vollbrecht 2 draft-ietf-aaa-authz-arch-00.txt Merit Network, Inc. 3 P. Calhoun 4 Sun Microsystems, Inc. 5 S. Farrell 6 Baltimore Technologies 7 L. Gommans 8 Cabletron Systems EMEA 9 G. Gross 10 Lucent Technologies 11 B. de Bruijn 12 Interpay Nederland B.V. 13 C. de Laat 14 Utrecht University 15 M. Holdrege 16 Lucent Technologies 17 D. Spence 18 Merit Network, Inc. 19 October 1999 21 AAA Authorization Framework 23 Status of this Memo 25 This document is an Internet-Draft and is in full conformance with 26 all provisions of Section 10 of RFC2026 [1]. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet- Drafts as reference 36 material or to cite them other than as "work in progress". 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This memo describes work in progress within the AAA Working Group. 45 Comments are welcome and should be submitted to aaa-wg@merit.edu. 47 Distribution of this memo is unlimited. 49 Copyright Notice 51 Copyright (C) The Internet Society 1999. All Rights Reserved. 53 Abstract 55 This memo serves as the base requirements for Authorization of 56 Internet Resources and Services (AIRS). It presents an architectural 57 framework for understanding the authorization of Internet resources 58 and services and derives requirements for authorization protocols. 60 Table of Contents 62 Status of this Memo ............................................ 1 63 Copyright Notice ............................................... 2 64 Abstract ....................................................... 2 65 1. Introduction ................................................ 3 66 2. Authorization Entities and Trust Relationships .............. 4 67 3. Message Sequences ........................................... 7 68 3.1. Single Domain Case ..................................... 7 69 3.1.1. The Agent Sequence .............................. 7 70 3.1.2. The Pull Sequence ............................... 8 71 3.1.3. The Push Sequence ............................... 9 72 3.2. Roaming ................................................ 10 73 3.3. Distributed Services ................................... 13 74 3.4. Combining Roaming and Distributed Services ............. 15 75 4. Relationship of Authorization and Policy .................... 16 76 4.1. Policy Retrieval ....................................... 16 77 4.2. Policy Evaluation ...................................... 17 78 4.3. Policy Enforcement ..................................... 17 79 4.4. Distributed Policy ..................................... 18 80 5. Use of Attribute Certificates ............................... 19 81 6. Resource Management ......................................... 22 82 6.1. Session Management ..................................... 23 83 6.2. The Resource Manager ................................... 24 84 7. AAA Message Forwarding and Delivery ......................... 25 85 8. End-to-End Security ......................................... 27 86 9. Streamlined Authorization Process ........................... 27 87 10. Summary of the Authorization Framework ..................... 28 88 11. Security Considerations .................................... 28 89 Glossary ....................................................... 30 90 References ..................................................... 31 91 Authors' Addresses ............................................. 32 93 1. Introduction 95 This document is one of a series of three documents prepared by the 96 AAA WG authorization subgroup dealing with the authorization 97 requirements for AAA protocols. The three documents are: 99 AAA Authorization Framework (this document) 100 AAA Authorization Requirements [2] 101 AAA Authorization Application Examples [3] 103 There is a demonstrated need for a common scheme which covers all 104 Internet services which offer Authorization. This common scheme will 105 address various functional architectures which meet the requirements 106 of basic services. We attempt to describe these architectures and 107 functions as a basis for deriving requirements for an authorization 108 protocol [2]. 110 These architectures include Policy structures, Certificate 111 Authorities, Resource Managers, Inter-Domain and Multi-Domain 112 schemes, and Distributed Services. The requirements are for the 113 expected use of Authorization services across these architectures. 115 A representative set of applications that may use this architecture 116 to support their authorization needs is presented in [3]. The 117 examples in [3] show how this framework may be used to meet a wide 118 variety of different authorization needs. 120 We expect that this work may be extended in the future to a more 121 comprehensive model and that the scheme described here will be 122 incorporated into a framework that includes authentication, 123 accounting and auditing. We have referenced a number of 124 authorization sources, but also recognize that there may be some that 125 we have missed and that should be included. Please notify one of the 126 authors of any such oversight so it can be corrected in a future 127 revision. 129 In general, it is assumed that the parties who are participating in 130 the authorization process have already gone through an authentication 131 phase. The authentication method used by those parties is outside 132 the scope of this document except to the extent that it influences 133 the requirements found in a subsequent authorization process. 134 Likewise, accounting requirements are outside the scope of this 135 document other than recording accounting data or establishing trust 136 relationships during an authorization that will facilitate a 137 subsequent accounting phase. 139 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 140 negatives, in the way described in RFC 2119 [4]. 142 2. Authorization Entities and Trust Relationships 144 The following framework is being presented in order to provide a 145 framework for discussing authorization requirements for a large 146 number of applications. The intent is to provide some common 147 vocabulary for the discussion. Terminology is introduced for basic 148 elements in the authorization transaction and for concepts that 149 appear to be common to all (or at least many) authorization 150 proposals. 152 Figure 1, below, identifies the basic conceptual entities that may 153 be participants in an authorization: 155 1. A User who wants access to a service or resource. 157 2. A User Home Organization (UHO) that has an agreement with the user 158 and checks whether the user is allowed to obtain the requested 159 service or resource. This entity may carry information required 160 to authorize the User, which might not be known to the Service 161 Provider (such as a credit limit). 163 3. A Service Provider's AAA Server which authorizes a service based 164 on an agreement with the User Home Organization without specific 165 knowledge about the individual User. This agreement may contain 166 elements that are not relevant to an individual user (e.g., the 167 total agreed bandwidth between the User Home Organization and the 168 Service Provider). 170 4. A Service Provider's Service Equipment which provides the service 171 itself. This might, for example, be a NAS in dial service, or a 172 Router in the QoS service, or a print server in the Internet 173 Printing service. 175 +------+ +-------------------------+ 176 | | | User Home Organization | 177 | | | +-------------------+ | 178 | | | | AAA Server | | 179 | | | | | | 180 | | | +-------------------+ | 181 | | | | 182 | | +-------------------------+ 183 | | 184 | | 185 | | 186 | User | +-------------------------+ 187 | | | Service Provider | 188 | | | +-------------------+ | 189 | | | | AAA Server | | 190 | | | | | | 191 | | | +-------------------+ | 192 | | | | 193 | | | +-------------------+ | 194 | | | | Service | | 195 | | | | Equipment | | 196 | | | +-------------------+ | 197 | | | | 198 +------+ +-------------------------+ 200 Fig. 1 -- The Basic Authorization Entities 202 These entities will be referenced in the authorization requirements. 204 There may be bilateral agreements between pairs of organizations 205 involved in an authorization transaction. Agreements between 206 organizations may take the form of formal contracts or Service Level 207 Agreements. Figure 2 uses double lines to show relationships that 208 may exist between the User and the User Home Organization and between 209 the User Home Organization and the Service Provider. 211 +------+ +-------------------------+ 212 | | | User Home Organization | 213 | |======| +-------------------+ | 214 | | | | AAA Server | | 215 | | | | | | 216 | | | +-------------------+ | 217 | | | | 218 | | +-------------------------+ 219 | | || 220 | | || 221 | | || 222 | User | +-------------------------+ 223 | | | Service Provider | 224 | | | +-------------------+ | 225 | | | | AAA Server | | 226 | | | | | | 227 | | | +-------------------+ | 228 | | | | 229 | | | +-------------------+ | 230 | | | | Service | | 231 | | | | Equipment | | 232 | | | +-------------------+ | 233 | | | | 234 +------+ +-------------------------+ 236 Fig. 2 -- Service Agreements 238 Authorization is based on these bilateral agreements between 239 entities. Agreements may be chained, as shown in figure 2. The User 240 has an agreement with the User Home Organization (e.g., the User may 241 have access to the service between 9:00 a.m. and 11:00 a.m. daily). 242 The User Home Organization has an agreement with the Service Provider 243 (e.g., that all requests for access will be granted, except between 244 5:00 a.m. and 10:00 a.m. on Sunday). The fulfillment of the User's 245 request depends on both agreements being honored. 247 Note that these agreements may be implemented by hand configuration 248 or by evaluation of Policy data stored in a Policy database. The 249 point is that there must be a set of known rules in place between 250 entities in order for authorization transactions to be executed. 252 Trust is necessary to allow each entity to "know" that the policy it 253 is authorizing is correct. This is a business issue as well as a 254 protocol issue. Trust is often established through third party 255 authentication servers (such as Kerberos), via a certificate 256 authority, by configuring shared secrets or passwords, or by sharing 257 a common facility (such as a connecting wire between processors). 258 These "static" trust relationships are necessary for authorization 259 transactions to take place. Static trust relationships are used in 260 an authorization sequence to establish a "dynamic" relationship 261 between the User and the Service Equipment. Several possible 262 authorization sequences are possible, each of which use the static 263 trust "chain" to have the user first be approved by the User Home 264 Organization, and then have the Service Provider accept the request 265 based on its trust of the User Home Organization. 267 3. Message Sequences 269 In general, the User Home Organization and the Service Provider are 270 different entities or different "administrative domains". In the 271 simplest case, however, the User Home Organization and the Service 272 Provider may be combined as a single entity. This case will be used 273 to describe three authorization sequences possible with the simple 274 case. 276 In following sections these concepts will be applied to more 277 complicated cases involving separate User Home Organization and 278 Service Provider entities (as in roaming) and multiple Service 279 Providers each with their own AAA Servers and Service Equipment (as 280 in distributed services). 282 3.1. Single Domain Case 284 This case includes the User, the Service Provider's AAA Server, and 285 the Service Provider's Service Equipment. Examples of this case 286 include a NAS supported by a standalone RADIUS server, or a QoS 287 Router supported by a local bandwidth broker. 289 The sequences considered in the following figures are the "agent", 290 "pull", and "push" sequences for the single domain case. 292 3.1.1. The Agent Sequence 294 In the agent sequence (see figure 3), the Service Provider AAA Server 295 functions as an agent between the User and the service itself. The 296 AAA Server receives a request from the User and forwards 297 authorization and possibly configuration information to the Service 298 Equipment. In this model, the User sends a request to the Service 299 Provider's AAA Server (1), which will apply a policy associated with 300 the User and the particular service being requested. The AAA Server 301 sends a request to the Service Equipment, and the Service Equipment 302 sets up whatever is requested (2). The Service Equipment then 303 responds to the AAA Server acknowledging that it has set up the 304 Service for the user (3). The AAA Server replies to the User telling 305 it that the Service is set up (4). 307 Depending on the nature of the service, further communication may 308 take place between the User and the Service Equipment. For this to 309 occur, there needs to be a binding between the User and the 310 authorized service. This requires further study. 312 +-------------------------+ 313 +------+ | Service Provider | 314 | | 1 | +-------------------+ | 315 | |------+->| AAA Server | | 316 | |<-----+--| | | 317 | | 4 | +-------------------+ | 318 | User | | | /|\ | 319 | | | |2 |3 | 320 | | | \|/ | | 321 | | | +-------------------+ | 322 | | | | Service | | 323 | | | | Equipment | | 324 | | | +-------------------+ | 325 +------+ | | 326 +-------------------------+ 328 Fig. 3 -- Agent Sequence 330 Example: A regular user may ask for 1 Mb/s bandwidth (1). The 331 bandwidth broker (AAA Server) tells the router (Service Equipment) to 332 set this user into the 1Mb/s "queue" (2). The router responds that 333 it has done so (3), and the bandwidth broker tells the User the 334 bandwidth is set up (4). 336 3.1.2. The Pull Sequence 338 The pull sequence (figure 4) is what is typically used in the Dialin 339 application, in the Mobile-IP proposal, and in some QoS proposals. 340 The User sends a request to the Service Equipment (1), which forwards 341 it to the Service Provider's AAA Server (2), which evaluates the 342 request and returns an appropriate response to the Service Equipment 343 (3), which sets up the service and tells the User it is ready (4). 345 +-------------------------+ 346 +------+ | Service Provider | 347 | | | +-------------------+ | 348 | | | | AAA Server | | 349 | | | | | | 350 | | | +-------------------+ | 351 | User | | /|\ | | 352 | | | |2 |3 | 353 | | | | \|/ | 354 | | 1 | +-------------------+ | 355 | |------+->| Service | | 356 | |<-----+--| Equipment | | 357 | | 4 | +-------------------+ | 358 +------+ | | 359 +-------------------------+ 361 Fig. 4 -- Pull Sequence 363 3.1.3. The Push Sequence 365 The push sequence (figure 5) requires that the User get from the 366 Service Provider's AAA Server a ticket or certificate verifying that 367 it is o.k. for the User to have access to the service (1,2). The 368 User includes the ticket in the request (3) to the Service Equipment. 369 The Service Equipment uses the ticket to verify that the request is 370 approved by the Service Provider's AAA Server. The Service Equipment 371 then sends an o.k. to the User (4). 373 The ticket the user gets from the Service Provider's AAA Server will 374 typically have some time limit on it. It may contain an indication 375 of service location, and in some applications, it might be used for 376 more than one request. 378 In the push sequence the communication between the AAA Server and the 379 Service Equipment is relayed through the User rather than directly 380 between themselves. 382 +-------------------------+ 383 +------+ | Service Provider | 384 | | 1 | +-------------------+ | 385 | |------+->| AAA Server | | 386 | |<-----+--| | | 387 | | 2 | +-------------------+ | 388 | User | | | 389 | | | | 390 | | | | 391 | | 3 | +-------------------+ | 392 | |------+->| Service | | 393 | |<-----+--| Equipment | | 394 | | 4 | +-------------------+ | 395 +------+ | | 396 +-------------------------+ 398 Fig. 5 -- Push Sequence 400 3.2. Roaming -- the User Home Organization is not the Service Provider 402 In many interesting situations, the organization that authorizes and 403 authenticates the User is different from the organization providing 404 the service. This situation has been explored in the Roaming 405 Operations (roamops) Working Group. For purposes of this discussion, 406 any situation in which the User Home Organization is different from 407 the Service Provider is considered to be roaming. 409 Examples of roaming include an ISP selling dialin ports to other 410 organizations or a Mobile-IP provider allowing access to a user from 411 another domain. 413 The same agent, pull and push sequences are possible with roaming. 414 If the Service Provider's AAA Server and the Service Equipment are 415 grouped as a logical entity for purposes of description, then the 416 following figures illustrate these cases. 418 +------+ +-------------------------+ 419 | | 1 | User Home Organization | 420 | |----->| +-------------------+ | 421 | | | | AAA Server | | 422 | |<-----| | | | 423 | | 4 | +-------------------+ | 424 | | | | 425 | | +-------------------------+ 426 | | | /|\ 427 | | |2 |3 428 | | \|/ | 429 | User | +-------------------------+ 430 | | | Service Provider | 431 | | | +-------------------+ | 432 | | | | AAA Server | | 433 | | | | | | 434 | | | +-------------------+ | 435 | | | | 436 | | | +-------------------+ | 437 | | | | Service | | 438 | | | | Equipment | | 439 | | | +-------------------+ | 440 | | | | 441 +------+ +-------------------------+ 443 Fig. 6 -- Roaming Agent Sequence 445 +------+ +-------------------------+ 446 | | | User Home Organization | 447 | | | +-------------------+ | 448 | | | | AAA Server | | 449 | | | | | | 450 | | | +-------------------+ | 451 | | | | 452 | | +-------------------------+ 453 | | /|\ | 454 | | |2 |3 455 | | | \|/ 456 | | +-------------------------+ 457 | | | Service Provider | 458 | User | | +-------------------+ | 459 | | | | AAA Server | | 460 | | 1 | | | | 461 | |----->| +-------------------+ | 462 | | | | 463 | |<-----| +-------------------+ | 464 | | 4 | | Service | | 465 | | | | Equipment | | 466 | | | +-------------------+ | 467 | | | | 468 +------+ +-------------------------+ 470 Fig. 7 -- Roaming Pull Sequence 472 +------+ +-------------------------+ 473 | | 1 | User Home Organization | 474 | |----->| +-------------------+ | 475 | | | | AAA Server | | 476 | |<-----| | | | 477 | | 2 | +-------------------+ | 478 | | | | 479 | | +-------------------------+ 480 | | 481 | | 482 | | 483 | User | +-------------------------+ 484 | | | Service Provider | 485 | | | +-------------------+ | 486 | | | | AAA Server | | 487 | | 3 | | | | 488 | |----->| +-------------------+ | 489 | | | | 490 | |<-----| +-------------------+ | 491 | | 4 | | Service | | 492 | | | | Equipment | | 493 | | | +-------------------+ | 494 | | | | 495 +------+ +-------------------------+ 497 Fig. 8 -- Roaming Push Sequence 499 3.3. Distributed Services 501 To provide a complete service to a user, offerings from several 502 service providers may need to be combined. An example would be a 503 user who requires a QoS service for a session that crosses multiple 504 ISPs. Any service that is provided by more than one Service Provider 505 acting in concert is a distributed service. Figure 9 illustrates 506 distributed services. 508 +-------------------+ +-------------------+ 509 +------+ | Org1 | | Org2 | 510 | | | +-------------+ | | +-------------+ | 511 | | | | AAA Server | | | | AAA Server | | 512 | | | | | | | | | | 513 | | | +-------------+ | | +-------------+ | 514 | User |======| |======| | 515 | | | +-------------+ | | +-------------+ | 516 | | | | Service | | | | Service | | 517 | | | | Equipment | | | | Equipment | | 518 | | | +-------------+ | | +-------------+ | 519 +------+ | | | | 520 +-------------------+ +-------------------+ 522 Fig. 9 -- Distributed Services 524 The agreements between entities in figure 9 imply that the request 525 from the User will be authenticated and authorized by the first 526 organization, then forwarded to the second organization. Note that 527 the sequence between User and Org1 may be different than between Org1 528 and Org2. The first might use a pull sequence, and the second might 529 use an agent sequence. This example is illustrated in figure 10. 531 +-------------------+ +-------------------+ 532 +------+ | Org1 | | Org2 | 533 | | | +-------------+ | 3 | +-------------+ | 534 | | | | AAA Server |--+------+->| AAA Server | | 535 | | | | |<-+------+--| | | 536 | | | +-------------+ | 6 | +-------------+ | 537 | User | | /|\ | | | | /|\ | 538 | | | |2 |7 | | |4 |5 | 539 | | | | \|/ | | \|/ | | 540 | | 1 | +-------------+ | | +-------------+ | 541 | |------+->| Service | | | | Service | | 542 | |<-----+--| Equipment | | | | Equipment | | 543 | | 8 | +-------------+ | | +-------------+ | 544 +------+ | | | | 545 +-------------------+ +-------------------+ 547 Fig. 10 -- A Possible Distributed Sequence 549 There are a number of other ways that authorization sequences for 550 distributed services can be set up. For example, it is possible 551 that, in order to reduce delay time in setting up a session, Org1 552 could send a response to the user before receiving a verification 553 that Org2 has authorized the service. In that case Org1 would need 554 to be able to revoke the authorization sent earlier if Org2 does not 555 send the authorization in some amount of time. 557 3.4. Combining Roaming and Distributed Services 559 Figure 11 shows a combination of Roaming and Distributed Services. 560 Contract and trust relationships may be set up in number of ways, 561 depending on a variety of factors, especially the business model. 563 +------+ +-------------------+ +-------------------+ 564 | | | User Home Org | | SuperOrg | 565 | | | +-------------+ | | +-------------+ | 566 | | | | AAA Server | | | | AAA Server | | 567 | | | | | | | | | | 568 | | | +-------------+ | | +-------------+ | 569 | | | | | | 570 | | +-------------------+ +-------------------+ 571 | | 572 | | 573 | | +-------------------+ +-------------------+ 574 | User | | Org1 | | Org2 | 575 | | | +-------------+ | | +-------------+ | 576 | | | | AAA Server | | | | AAA Server | | 577 | | | | | | | | | | 578 | | | +-------------+ | | +-------------+ | 579 | | | | | | 580 | | | +-------------+ | | +-------------+ | 581 | | | | Service | | | | Service | | 582 | | | | Equipment | | | | Equipment | | 583 | | | +-------------+ | | +-------------+ | 584 | | | | | | 585 +------+ +-------------------+ +-------------------+ 587 Fig. 11 -- Roaming and Distributed Services 589 New entities that combine or add capabilities can be created to meet 590 business needs. In figure 11, one such possibility, a SuperOrg 591 entity is shown. The idea is that this entity would provide 592 authentication and authorization for organizations that are providing 593 services to end-users. It could be considered to be a wholesaler or 594 broker. While not all authorization will require having a broker, 595 authorization protocols should allow such entities to be created to 596 meet legitimate requirements. 598 Having considered the basic players and how they interact, we will 599 now consider different ways that authorization data may be stored in 600 the network. 602 4. Relationship of Authorization and Policy 604 The Policy Framework (policy) Working Group is seeking to provide a 605 framework to represent, manage, and share policies and policy 606 information in a vendor-independent, interoperable, scalable manner. 607 [5],[6],[7]. This section explores the relationship of policy and 608 authorization and sets the stage for defining protocol requirements 609 for supporting policy when included as part of multi-domain 610 authorization. The work presented here builds on the policy 611 framework, extending it to support policy across multiple domains. 613 One view of an authorization is that it is the result of evaluating 614 policies of each organization that has an interest in the 615 authorization decision. In this document the assumption is that each 616 administration may have policies which may be indexed by user, by 617 service, or by other attributes of the request. The policies of each 618 administration are defined independently of other administrations. 620 Each independent policy must be 1) retrieved, 2) evaluated, and 3) 621 enforced. 623 4.1. Policy Retrieval 625 Policy definitions are maintained and stored in a policy repository 626 [7] by (or on behalf of) the organization that requires them. The 627 Policy Framework WG is working on a way to describe policy [6]. 628 Other implementations describe policy as a set of ACL lists. Policy 629 definitions must be retrieved in order to be evaluated and enforced. 630 Policy Definitions can be indexed by requester, by service attribute, 631 or by some other key. The organization requiring the policy is also 632 responsible for determining which policy is to be applied to a 633 specific authorization request. 635 Policy retrieval is typically done by the administration that defines 636 the policy or by an agent acting for that administration. Thus a 637 policy defining the times of day that a particular User is allowed to 638 connect to the network is maintained and retrieved by the User 639 Organization. A policy defining a time that ports will be unusable 640 because of maintenance is maintained and retrieved by the Service 641 Provider. 643 Note that some implementation may choose to have the Service Provider 644 retrieve a policy from the User Home Organization using a distributed 645 directory access protocol. This may be appropriate in some cases, 646 but is not a general solution. To understand why, suppose the remote 647 administration and the home administration communicate via a broker 648 which proxies their communications. In this case the remote and home 649 administrations have no prior relationship, and therefore the home 650 administration directory is unlikely to be open for access by the 651 remote administration and vice versa. 653 4.2. Policy Evaluation 655 Evaluation of policy requires access to information referenced by the 656 policy. Often the information required is not available in the 657 administration where the policy is retrieved. For example, checking 658 that a user is allowed to login at the current time can readily be 659 done by the User Home Organization because the User Home Organization 660 has access to current time. But authorizing a user requiring a 2Mb/s 661 path with less than 4 hops requires information available at a 662 Service Provider and not directly available to the UHO, so the UHO 663 must either 1) have a way to query a remote administration for the 664 needed information or 2) forward the policy to the remote 665 administration and have the remote administration do the actual 666 evaluation or 3) attempt somehow to "shadow" the authoritative source 667 of the information (e.g by having the Service Provider send updates 668 to the UHO). 670 Applications might support either 1) or 2), and a general 671 authorization protocol must allow both. Case 3) is not considered 672 further as shadowing seems too "expensive" to be supported by an AAA 673 protocol. 675 An example of case 1 is when a Service Provider forwards a request to 676 a UHO which includes a query for the clearance code of the User. The 677 Service Provider policy includes reference to the clearance code and 678 the information in the reply is used as input to that policy. 680 An example of case 2 is when the UHO approves an authorization 681 conditional on the Service Provider confirming that there is 682 currently a specific resource available for its use. The UHO 683 includes the "policy" along with a conditional authorization to the 684 Service Provider. 686 4.3. Policy Enforcement 688 Policy Enforcement is typically done by the Service Provider on the 689 Service Equipment. The Service Equipment is equivalent to the Policy 690 Target described in the Policy Framework [7]. Thus a NAS may enforce 691 destination IP address limits via "filters" and a Router may enforce 692 QoS restrictions on incoming packets. The protocol that sends the 693 information between the Service Equipment and the Service Provider 694 AAA Server may be specific to the Service Equipment, but it seems 695 that the requirements are not different in kind from what is required 696 between other AAA servers. 698 In particular, an AAA Server could send a "policy" to the Service 699 Equipment stating what the equipment should do under various 700 situations. The Service equipment should either set up to "enforce" 701 the policy or reject the request. 703 The AAA Server could also send a query to the Service Equipment for 704 information it requires to evaluate a policy. 706 4.4. Distributed Policy 708 A policy is retrieved by a Policy Retrieval Point (PRP) from a Policy 709 Repository, evaluated at a Policy Decision Point (PDP) or Policy 710 Consumer [7], and enforced at a Policy Enforcement Point (PEP) or 711 Policy Target [6]. 713 Generally, any of the AAA Servers involved in an authorization 714 transaction may retrieve a policy or evaluate a policy, and any of 715 the Service Equipment may enforce a policy. Policy Repositories may 716 reside on any of the AAA Servers or be located elsewhere in the 717 network. 719 Information against which policy conditions are evaluated (such as 720 resource status, session state, or time of day) are accessible at 721 Policy Information Points (PIPs) and might be accessed using Policy 722 Information Blocks (PIBs). An interesting question in any 723 authorization application that uses policy is where are the PDPs, 724 PRPs, PIPs and PEPs? 726 Figure 12 shows which policy elements may be available at different 727 points in the model. In distributed services, there may be multiple 728 Service Providers involved in the authorization transaction, and each 729 may act as the policy elements shown below. 731 Note that the User (or requester) may also be a PRP (e.g. use policy 732 description to specify what service is being requested), a PIP (have 733 information needed by other entities to evaluate their policy), and a 734 PDP (decide if it will accept a service with specific parameters). 736 +------+ +------------------------------+ 737 | | | User Home Organization | 738 | | | +-------------------+ PRP | 739 | | | | AAA Server | PIP | 740 | | | | | PDP | 741 | | | +-------------------+ | 742 | | | | 743 | | +------------------------------+ 744 | | 745 | | 746 | | +------------------------------+ 747 | User | | Service Provider | 748 | | | +-------------------+ PRP | 749 | PRP | | | AAA Server | PIP | 750 | PIP | | | | PDP | 751 | PDP | | +-------------------+ | 752 | | | | 753 | | | +-------------------+ | 754 | | | | Service | PIP | 755 | | | | Equipment | PEP | 756 | | | +-------------------+ | 757 | | | | 758 +------+ +------------------------------+ 760 PRP = Policy Retrieval Point 761 PIP = Policy Information Point 762 PDP = Policy Decision Point 763 PEP = Policy Enforcement Point 765 Fig. 12 -- Where Different Policy Elements May be Located 767 An AAA protocol must be able to transport both policy definitions and 768 the information needed to evaluate policies. It must also support 769 queries for policy information. 771 5. Use of Attribute Certificates to Store Authorization Data 773 This section outlines another mechanism that could be used for 774 securely transporting the attributes on which an authorization 775 decision is to be made. Work on X.509 Attribute Certificates is 776 currently being undertaken in the Public Key Infrastructure (PKIX) 777 Working Group [8]. This proposal is largely based on that work. 779 When considering authorization using certificate-based mechanisms, 780 one is often less interested in the identity of the entity than in 781 some other attributes, (e.g. roles, account limits etc.), which 782 should be used to make an authorization decision. 784 In many such cases, it is better to separate this information from 785 the identity for management, security, interoperability or other 786 reasons. However, this authorization information may also need to be 787 protected in a fashion similar to a public key certificate. The name 788 used here for such a structure is an Attribute Certificate (AC) which 789 is a digitally signed (certified) set of attributes. 791 An AC is a structure that is similar to an X.509 public key 792 certificate [9] with the main difference being that it contains no 793 public key. The AC typically contains group membership, role, 794 clearance and other access control information associated with the AC 795 owner. A syntax for ACs is also defined in the X.509 standard. 797 When making an access decision based on an AC, an access decision 798 function (in a PEP, PDP or elsewhere) may need to ensure that the 799 appropriate AC owner is the entity that has requested access. The 800 linkage between the request and the AC can be achieved if the AC has 801 a "pointer" to a Public Key Certificate (PKC) for the requester and 802 that the PKC has been used to authenticate the request. Other forms 803 of linkage can be defined which work with other authentication 804 schemes. 806 As there is often confusion about the difference between public key 807 certificates (PKC's) and attribute certificates (ACs), an analogy may 808 help. A PKC can be considered to be like a passport: it identifies 809 the owner, it tends to be valid for a long period, it is difficult to 810 forge, and it has a strong authentication process to establish the 811 owner's identity. An AC is more like an entry visa in that it is 812 typically issued by a different authority than the passport issuing 813 authority, and it doesn't have as long a validity period as a 814 passport. Acquiring an entry visa typically requires presenting a 815 passport that authenticates that owner's identity. As a consequence, 816 acquiring the entry visa becomes a simpler procedure. The entry visa 817 will refer to the passport as a part of how that visa specifies the 818 terms under which the passport owner is authorized to enter a 819 country. 821 In conjunction with authentication services, ACs provide a means to 822 transport authorization information securely to applications. 823 However, there are a number of possible communication paths that an 824 AC may take. 826 In some environments, it is suitable for a client to "push" an AC to 827 a server. This means that no new connections between the client and 828 server domains are required. It also means that no search burden is 829 imposed on servers, which improves performance. 831 In other cases, it is more suitable for a client simply to 832 authenticate to the server and for the server to request the client's 833 AC from an AC issuer or a repository. A major benefit of the this 834 model is that it can be implemented without changes to the client and 835 client/server protocol. It is also more suitable for some inter- 836 domain cases where the client's rights should be assigned within the 837 server's domain, rather than within the client's "home" domain. 839 There are a number of possible exchanges that can occur, and there 840 are three entities involved: client, server, and AC issuer. In 841 addition the use of a directory service as a repository for AC 842 retrieval may be supported. 844 Figure 13 shows an abstract view of the exchanges that may involve 845 ACs. Note that the lines in the diagram represent protocols which 846 must be defined, not data flows. The PKIX working group will define 847 the required acquisition protocols. One candidate for the lookup 848 protocols is LDAP (once an LDAP schema exists which states where an 849 AC is to be found). 851 +--------------+ +---------------+ 852 | AAA Server/ | | | 853 | AC Issuer +----+ | Directory | 854 | | | | | 855 +--+-----------+ | Server +-------+-------+ 856 | | Acquisition | 857 |Client | |Server 858 |Acquisition +----------------------+ |Lookup 859 | | | 860 +--+-----------+ +--+----+-------+ 861 | | AC in application | Service | 862 | User +------------------------+ Equipment/ | 863 | | protocol | AAA Server | 864 +--+-----------+ +---------------+ 865 | 866 | Client Lookup 867 +--+-----------+ 868 | | 869 | Directory | 870 | | 871 +--------------+ 873 Fig. 13 -- AC Exchanges 875 Figure 14 shows the data flows which may occur in one particular 876 case, that termed "push" above (section 2.1.3). 878 +--------------+ 879 | AAA Server/ | 880 | AC Issuer | 881 | | 882 +--+-----------+ 883 | 884 |Client 885 |Acquisition (1) 886 | 887 +--+-----------+ +---------------+ 888 | | AC in application | Service | 889 | User +------------------------+ Equipment/ | 890 | | protocol (2) | AAA Server | 891 +--------------+ +---------------+ 893 Fig. 14 -- One example of an AC exchange 895 In the diagram, the user first contacts the AC Issuer and then 896 incorporates the AC into the application protocol. The Service 897 Equipment must then validate the AC and use it as the basis for the 898 access decision (this functionality may be distributed between a PEP 899 and PDP). 901 6. Resource Management 903 Authorization requests may be chained through a set of servers, as 904 described in previous sections. Each of the servers may have a 905 contractual relationship with servers on either side of it in the 906 chain. In many of the applications being considered, the 907 authorization results in establishing of an ongoing service which we 908 call a session. Each of the servers involved in the authorization 909 may also want to keep track of the state of the session, and be able 910 to effect changes to the session if required. To make it simple to 911 discuss this capability, we assume that each AAA Server MAY have a 912 Resource Manager component. Resource Managers tracking the same 913 session need to be able to initiate changes to the session, and to 914 inform other Resource Managers when changes occur. Communication 915 between Resource Managers creates requirements for an authorization 916 protocol. 918 An example of the use of resource management might be a user which 919 sets up a QoS path through two ISPs, and while this path is active, 920 one of the ISPs gets a request for more bandwidth from a higher 921 priority user. The ISP may need to take some bandwidth from a the 922 lower priority user's previously allocated session and give it to the 923 new request. To do this, each of the administrations in the 924 authorization path must be informed and agree to the change (this 925 could be considered to be "authorizing the new value"). 927 6.1. Session Management and State Synchronization 929 When an AAA Server grants authorization of some resource to an AAA 930 requester (either a User or another AAA Server), the server may need 931 to maintain session state information. This is used to make 932 decisions about new sessions based on the state of current sessions, 933 and to allow monitoring of sessions by all interested AAA Servers. 935 Each session is identified by a session identifier, which must be 936 unique within each AAA Server. Communication between AAA Servers 937 must include the session identifier. It is desirable that the 938 session identifier is the same across all AAA servers, otherwise each 939 server will have to map identifiers from other servers to its own 940 identifiers. A single session identifier significantly simplifies 941 auditing and session control functions. 943 Maintaining session state across AAA administrative boundaries 944 increases the complexity of the problem, especially if each AAA 945 Server in the trust chain must keep state as well. This can be 946 viewed as an interdomain database replication problem. The protocol 947 must include tools to help manage replicated state. Some of the 948 problems to be addressed are: 950 a) Service Equipment must be able to notify its Resource Manager when 951 a session terminates or changes state in some other way. The 952 Resource Manager must inform other Resource Managers which keep 953 state for this session. 955 b) The Resource Manager will need to set a time limit for each 956 session which must be refreshed by having the Resource Manager 957 query for authoritative status or by having the authoritative 958 source send periodic keep alive messages that are forwarded to all 959 Resource Managers in the authorization chain. Determining the 960 appropriate session lifetime may be application specific and 961 depends on the acceptable level of risk. If the service being 962 offered is billed based on time, the session lifetime may need to 963 be relatively small; if the service is billed on usage, the 964 lifetime may be relatively large. 966 c) Any Resource Manager in the chain must have the ability to 967 terminate a session. This requires the Resource Manager to have 968 knowledge of at least the adjacent AAA Servers in the 969 authorization chain. 971 An example of how resource management can be used is in the PPP 972 dialin application. A home ISP may wish to restrict the number of 973 concurrent sessions that a user can have at any given time. This is 974 particularly important when service providers give all-you-can-eat 975 Internet access. The possibility for fraud is quite large, since a 976 user could provide his or her username/password to many people, 977 causing a loss of revenue. Resource management would allow the home 978 ISP AAA server to identify when a user is active and to reject any 979 authorization request for the user until termination indication is 980 received from the NAS or until the session expires. 982 6.2. The Resource Manager 984 This section describes the functions of the Resource Manager in more 985 detail. 987 The Resource Manager is the component which tracks the state of 988 sessions associated with an AAA Server or Service Equipment. It also 989 may allocate resources to a session (e.g. IP addresses) and may track 990 use of resources allocated by peer resource managers to a session 991 (e.g. bandwidth in a foreign administrative domain). The resource 992 manager also provides interfaces to allow the User to acquire or 993 release authorized sessions. 995 The Resource Manager maintains all session specific AAA state 996 information required by the AAA Server. That state information may 997 include pointers to peer Resource Managers in other administrative 998 domains that possess additional AAA state information that refers to 999 the same session. The Resource Manager is the anchor point in the 1000 AAA Server from which a session can be controlled, monitored, and 1001 coordinated even if that session is consuming network resources or 1002 services across multiple Service Provider administrative domains. 1004 The Resource Manager has several important functions: 1006 a) It allows a Service Provider operations staff to inspect the 1007 status of any of the allocated resources and services including 1008 resources that span foreign Service Provider administrative 1009 boundaries. The peer Resource Managers will cooperatively share 1010 only the state information subset that is required to assist in 1011 diagnosing cross-domain trouble tickets. The network operator may 1012 also modify or altogether cancel one of the User's active 1013 authorizations. 1015 b) It is the process contacted by other Resource Managers to inform 1016 the AAA Server that a specific session has been cancelled. This 1017 information is relayed to the other peer Resource Managers that 1018 also know about that session and hence must cancel it. 1020 c) The Resource Manager conceals the identity and location of its 1021 private internal AAA components from other administrative domains 1022 and from the User, while at the same time facilitating cooperation 1023 between those domains. 1025 d) The Resource Manager cooperates with "policy servers" or Policy 1026 Decision Points (PDPs). The Resource Manager maintains internal 1027 state information, possibly complex cross-administrative domain 1028 information, supported by dialogues with its peer Resource 1029 Managers. A policy server can use the state information when 1030 evaluating a particular policy. 1032 e) The separation of the Resource Manager and the policy server into 1033 two distinct architectural components allows a single session to 1034 span multiple administrative domains, where each administrative 1035 domain has one or more policy server cooperating with its Resource 1036 Manager. 1038 AAA resource managers will normally use the same trust relationships 1039 needed for authorization sequences. It is possible for independent 1040 relationships to be established, but that is discouraged. 1042 7. AAA Message Forwarding and Delivery 1044 An AAA Server is responsible for securely forwarding AAA messages to 1045 the correct destination system or process in the AAA infrastructure. 1046 Two well known examples are forwarding AAA messages for a roaming AAA 1047 service, and forwarding AAA messages for a distributed AAA service. 1048 The same principle can also be applied to intra-domain 1049 communications. The message forwarding is done in one of two modes. 1051 The first mode is when an AAA server needs to forward a message to a 1052 peer AAA server that has a known "logical destination address" that 1053 must be resolved by an application-specific procedure into its actual 1054 network address. Typically the forwarding procedure indexes into a 1055 database by an application-specific identifier to discover the peer's 1056 network address. For example, in the roaming dialin application, the 1057 application-specific identifier may be an NAI. A bandwidth brokerage 1058 application would use other search indices unique to its problem 1059 domain to select the addressed peer AAA server. After the address 1060 resolution procedure has completed successfully, then the AAA server 1061 transmits the message to its peer over the connection associated with 1062 that destination network address. 1064 The second mode is when the AAA server already has an established 1065 session representing an authorization. The session's state contains 1066 the addressing and context used to direct the message to its 1067 destination peer AAA server, PDP, PEP, or User. The message is sent 1068 over the AAA server's connection to that destination peer, 1069 multiplexed with other session's messages. The message must be 1070 qualified by a session identifier that is understood by both end 1071 points. The AAA message's destination may be either intra- 1072 administrative domain, or inter-administrative domain. In the former 1073 case, the destination process may reside on the same system as the 1074 AAA server. 1076 In addition to the above message forwarding processing, the 1077 underlying message delivery service must meet the following 1078 requirements: 1080 - Unicast capability -- An end system can send a message to any 1081 other end system with minimal latency of session setup/disconnect 1082 overhead messages, and no end system overhead of keeping state 1083 information about every potential peer. 1085 - Data integrity and error detection -- This data transport protocol 1086 assumes an underlying datagram network layer service that includes 1087 packet discard on error detection, and data integrity protection 1088 against third party modifications. 1090 - Reliable data transport assurance -- When an end system 1091 successfully receives a message marked receipt requested, it must 1092 acknowledge that message to the sending system by either 1093 piggybacking the acknowledgement on an application-specific reply 1094 message, or else as a standalone acknowledgement message. The 1095 sending system maintains a retry timer; when the timer expires, 1096 the sending system retransmits a copy of its original message. It 1097 gives up after a configurable number of unsuccessful retries. 1099 - Sequenced data delivery -- If multiple messages are sent between a 1100 pair of end systems, those messages are delivered to the addressed 1101 application in the same order as they were transmitted. 1102 Duplicates are silently suppressed. 1104 - Responsive to network congestion feedback -- When the network 1105 enters into congestion, the end systems must detect that 1106 condition, and they must back off their transmission rate until 1107 the congestion subsides. The back off and recovery algorithms 1108 must avoid oscillations. 1110 8. End-to-End Security 1112 When AAA servers communicate through intermediate AAA servers, such 1113 as brokers, it may be necessary that a part of the payload be secure 1114 between the originator and the target AAA server. The security 1115 requirement may consist of one or more of the following: end-to-end 1116 message integrity, confidentiality, replay protection, and 1117 nonrepudiation. Furthermore, it is a requirement that intermediate 1118 AAA servers be able to append information such as local policy to a 1119 message before forwarding the message to its intended destination. 1120 It may also be required that an intermediate AAA Server sign such 1121 appended information. 1123 This requirement has been clearly documented in [10], which describes 1124 many current weaknesses of the RADIUS protocol [11] in roaming 1125 networks since RADIUS does not provide such functionality. One 1126 well-known attack is the ability for the intermediate nodes to modify 1127 critical accounting information, such as a session time. 1129 Most popular security protocols (e.g. IPSec, SSL, etc) do not provide 1130 the ability to secure a portion of the payload. Therefore, it may be 1131 necessary for the AAA protocol to implement its own security 1132 extensions to provide end-to-end security. 1134 9. Streamlined Authorization Process 1136 The techniques described above allow for great flexibility in 1137 distributing the components required for authentication and 1138 authorization. However, working groups such as Roamops and MobileIP 1139 have identified requirements to minimize Internet traversals in order 1140 to reduce latency. To support these requirements, data fields 1141 necessary for both authentication and authorization SHOULD be able to 1142 be carried in a single message set. This is especially important 1143 when there are intermediate servers (such as Brokers) in the AAA 1144 chain. 1146 Furthermore, it should be possible for the Brokers to allow end-to- 1147 end (direct) authentication and authorization. This can be done as 1148 follows. The User Home Organization generates a ticket which is 1149 signed using the UHO's private key. The ticket is carried in the 1150 accounting messages. The accounting messages must flow through the 1151 Broker since the Broker is acting as the settlement agent and 1152 requires this information. There are Brokers that will require to be 1153 in the authentication and authorization path as well since they will 1154 use this information to detect fraudulent activity, so the above 1155 should be optional. 1157 In order for end-to-end authentication and authorization to occur, it 1158 may be necessary for the Broker to act as a certificate authority. 1159 All members of the roaming consortium would be able to trust each 1160 other (to an extent) using the certificates. A Service Provider's 1161 AAA server that sends a request to the Broker should be able to 1162 receive a redirect message which would allow the two peers (Service 1163 Provider and UHO) to interact directly. The redirect message from 1164 the Broker should include the UHO's certificate, which eliminates the 1165 Service Provider from accessing the certificate archive. The request 1166 from the Service Provider could include its own certificate, and a 1167 token from the Broker's redirect message that is timestamped and 1168 guarantees that the Service Provider is in good standing with the 1169 Broker. This eliminates the home domain from accessing the 1170 Certificate Revocation List (CRL). 1172 10. Summary of the Authorization Framework 1174 The above has introduced the basic players in an authorization 1175 transaction as User, User Home Organization, Service Provider's AAA 1176 Server, and Service Equipment. It has discussed relationships 1177 between entities based on agreements or contracts, and on "trust". 1178 Examples of authorization sequences have been given. 1180 Concepts of roaming and distributed services have been briefly 1181 described. Combination of roaming and distributed services was also 1182 considered and the concept of a "wholesaler" or Broker was 1183 introduced. We have considered the use of policies and attribute 1184 certificates to store and transmit authorization data. We discussed 1185 the problem of managing the resources to which access has been 1186 authorized including the problem of tracking state information for 1187 session-oriented services, and we defined the Resource Manager 1188 component of a AAA Server. We considered the problem of forwarding 1189 AAA messages among servers in possibly different administrative 1190 domains. We considered the need for end-to-end security of portions 1191 of the payload of authorization messages that pass through 1192 intermediate AAA Servers. Finally we stressed the need for support 1193 of a streamlined authorization process that minimizes delay for 1194 latency-sensitive applications. 1196 The intent is that this will provide support for discussing and 1197 understanding requirements of specific applications that need 1198 authorization services. 1200 11. Security Considerations 1202 Authorization is itself a security mechanism. As such, it is 1203 important that authorization protocols cannot easily be abused to 1204 circumvent the protection they are intended to ensure. It is the 1205 responsibility of protocol designers to design their protocols to be 1206 resilient against well-known types of attacks. The following are 1207 some considerations that may guide protocol designers in the 1208 development of authorization protocols. 1210 Authorization protocols must not be susceptible to replay attacks. 1211 If authentication data is carried with the authorization data, for 1212 example, the authentication protocol used must either be impervious 1213 to replay or else the confidentiality of the authentication data must 1214 be protected. 1216 If proxying is required, the authorization protocol must not be 1217 susceptible to man-in-the-middle attacks. 1219 If the push model is used, the confidentiality of the authorization 1220 data must be ensured so that it may not be hijacked by third parties 1221 and used to obtain a service fraudulently. 1223 If the agent model is used, the binding between the authorization and 1224 the service itself must be protected to prevent service authorized to 1225 one party from being fraudulently received by another. 1227 In addition to guarding against circumvention, authorization 1228 protocols designed according to this framework will have some 1229 intrinsic security requirements. These are included among the 1230 requirements in [2] and summarized briefly below. 1232 Among the intrinsic security needs is the fact that authorization 1233 protocols may carry sensitive information. It is necessary to 1234 protect such information from disclosure to unauthorized parties 1235 including (as discussed in section 8) even certain parties involved 1236 in the authorization decision. 1238 We have discussed the use of multi-party trust chains involving 1239 relaying of authorization data through brokers or other parties. In 1240 such cases, the integrity of the chain must be maintained. It may be 1241 necessary to protect the data exchanged between parties using such 1242 mechanisms as encryption and digital signatures. 1244 Finally, because authorization will be necessary to gain access to 1245 many Internet services, a denial of service attack against an 1246 authorization server can be just as effective as a denial of service 1247 attack against the service equipment itself in preventing access to 1248 Internet services. 1250 Glossary 1252 Attribute Certificate -- structure containing authorization 1253 attributes which is digitally signed using public key 1254 cryptography. 1256 Contract Relationship -- a relation established between two or more 1257 business entities where terms and conditions determine the 1258 exchange of goods or services. 1260 Distributed Service -- a service that is provided by more than one 1261 Service Provider acting in concert. 1263 Dynamic Trust Relationship -- a secure relationship which is 1264 dynamically created between two entities who may never have had 1265 any prior relationship. This relationship can be created if the 1266 involved entities have a mutually trusted third party. Example: A 1267 merchant trusts a cardholder at the time of a payment transaction 1268 because they both are known by a credit card organization. 1270 Policy Decision Point (PDP) -- The point where policy decisions are 1271 made. 1273 Policy Enforcement Point (PEP) -- The point where the policy 1274 decisions are actually enforced. 1276 Resource Manager -- the component of an AAA Server which tracks the 1277 state of sessions associated with the AAA Server or its associated 1278 Service Equipment and provides an anchor point from which a 1279 session can be controlled, monitored, and coordinated. 1281 Roaming -- An authorization transaction in which the Service Provider 1282 and the User Home Organization are two different organizations. 1283 (Note that the dialin application is one for which roaming has 1284 been actively considered, but this definition encompasses other 1285 applications as well.) 1287 Security Association -- a collection of security contexts, between a 1288 pair of nodes, which may be applied to protocol messages exchanged 1289 between them. Each context indicates an authentication algorithm 1290 and mode, a secret (a shared key, or appropriate public/private 1291 key pair), and a style of replay protection in use. [12] 1293 Service Equipment -- the equipment which provides a service. 1295 Service Provider -- an organization which provides a service. 1297 Static Trust Relationship -- a pre-established secure relationship 1298 between two entities created by a trusted party. This 1299 relationship facilitates the exchange of AAA messages with a 1300 certain level of security and traceability. Example: A network 1301 operator (trusted party) who has access to the wiring closet 1302 creates a connection between a user's wall outlet and a particular 1303 network port. The user is thereafter trusted -- to a certain 1304 level -- to be connected to this particular network port. 1306 User -- the entity seeking authorization to use a resource or a 1307 service. 1309 User Home Organization (UHO) -- An organization with whom the User 1310 has a contractual relationship which can authenticate the User and 1311 may be able to authorize access to resources or services. 1313 References 1315 [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", 1316 RFC 2026, BCP 9, October 1996. 1318 [2] Vollbrecht, John, et al, "AAA Authorization Requirements", 1319 draft-ietf-aaa-authorization-reqs-01.txt, October 1999. 1321 [3] Vollbrecht, John, et al, "AAA Authorization Application 1322 Examples", draft-ietf-aaa-authz-samp-00.txt, October 1999. 1324 [4] Bradner, Scott, "Key words for use in RFCs to Indicate 1325 Requirement Levels", RFC 2119, BCP 14, March 1997. 1327 [5] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Framework 1328 Core Information Model", draft-ietf-policy-core-schema-03.txt, 1329 May 1999. 1331 [6] Strassner, John, Stephen Schleimer, "Policy Framework Definition 1332 Language", draft-ietf-policy-framework-pfdl-00.txt, November 1333 1998. 1335 [7] Stevens, Mark, "Policy Framework", draft-ietf-policy-framework- 1336 00.txt, September 1999. 1338 [8] Farrell, Stephen and Russell Housley, "An Internet 1339 AttributeCertificate Profile for Authorization", draft-ietf- 1340 pkix-ac509prof-01.txt, October 1999. 1342 [9] Housley, Russell et al, "Internet X.509 Public Key 1343 Infrastructure -- Certificate and CRL Profile", RFC 2459, 1344 January 1999. 1346 [10] Aboba, Bernard and John R. Vollbrecht, "Proxy Chaining and 1347 Policy Implementation in Roaming", RFC 2607, June 1999. 1349 [11] Rigney, Carl, Allan C. Rubens, William Allen Simpson, and Steve 1350 Willens, "Remote Authentication Dial In User Service (RADIUS)", 1351 RFC 2138, April 1997. 1353 [12] Perkins, Charles, "IP Mobility Support", RFC 2002, October 1996. 1355 [13] Yavatkar, Raj, Dimitrios Pendarakis, and Roch Guerin, "A 1356 Framework for Policy-based Admission Control", draft-ietf-rap- 1357 framework-03.txt, April 1999. 1359 Authors' Addresses 1361 John R. Vollbrecht 1362 Merit Network, Inc. 1363 4251 Plymouth Rd., Suite 2000 1364 Ann Arbor, MI 48105 1365 USA 1367 Phone: +1 734 763 1206 1368 Fax: +1 734 647 3745 1369 EMail: jrv@merit.edu 1371 Pat R. Calhoun 1372 Network and Security Research Center, Sun Labs 1373 Sun Microsystems, Inc. 1374 15 Network Circle 1375 Menlo Park, California, 94025 1376 USA 1378 Phone: +1 650 786 7733 1379 Fax: +1 650 786 6445 1380 EMail: pcalhoun@eng.sun.com 1382 Stephen Farrell 1383 Baltimore Technologies 1384 61 Fitzwilliam Lane 1385 Dublin 2 1386 Ireland 1388 Phone: +353 1 647 7406 1389 Fax: +353 1 647 7499 1390 EMail: stephen.farrell@baltimore.ie 1392 Leon Gommans 1393 Cabletron Systems EMEA 1394 Kerkplein 24 1395 2841 XM Moordrecht 1396 The Netherlands 1398 Phone: +31 182 379278 1399 Email: gommans@cabletron.com 1401 George M. Gross 1402 Lucent Technologies 1403 184 Liberty Corner Road, m.s. LC2N-D13 1404 Warren, NJ 07059 1405 USA 1407 Phone: +1 908 580 4589 1408 Fax: +1 908 580 7430 1409 Email: gmgross@lucent.com 1411 Betty de Bruijn 1412 Interpay Nederland B.V. 1413 Eendrachtlaan 315 1414 3526 LB Utrecht 1415 The Netherlands 1417 Phone: +31 30 2835104 1418 Email: betty@euronet.nl 1420 Cees T.A.M. de Laat 1421 Physics and Astronomy dept. 1422 Utrecht University 1423 Pincetonplein 5, 1424 3584CC Utrecht 1425 Netherlands 1427 Phone: +31 30 2534585 1428 Phone: +31 30 2537555 1429 EMail: delaat@phys.uu.nl 1431 Matt Holdrege 1432 Lucent Technologies 1433 1701 Harbor Bay Pkwy. 1434 Alameda, CA 94502 1435 USA 1437 Phone: +1 510 747 2711 1438 Email: holdrege@lucent.com 1440 David W. Spence 1441 Merit Network, Inc. 1442 4251 Plymouth Rd., Suite 2000 1443 Ann Arbor, MI 48105 1444 USA 1446 Phone: +1 734 615 2630 1447 Fax: +1 734 647 3745 1448 EMail: dwspence@merit.edu