idnits 2.17.1 draft-ietf-aaa-authz-samp-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 53 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. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1198 has weird spacing: '...uipment are e...' == 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 8958 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 2477 (ref. '5') == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-02 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '6') ** Obsolete normative reference: RFC 2486 (ref. '7') (Obsoleted by RFC 4282) ** Obsolete normative reference: RFC 2138 (ref. '8') (Obsoleted by RFC 2865) -- Possible downref: Normative reference to a draft: ref. '9' ** Obsolete normative reference: RFC 2002 (ref. '10') (Obsoleted by RFC 3220) -- No information found for draft-ietf-aaa-mobile-ip-req - is the name correct? -- Possible downref: Normative reference to a draft: ref. '11' -- No information found for draft-hiller-cdma2000-AAA - is the name correct? -- Possible downref: Normative reference to a draft: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 2566 (ref. '14') (Obsoleted by RFC 2911) -- No information found for draft-ietf-trade-iotp-v1 - is the name correct? -- Possible downref: Normative reference to a draft: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 14 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-samp-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 Application Examples 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 describes several examples of applications requiring 56 authorization. Each application is described in terms of a 57 consistent framework, and specific authorization requirements of each 58 application are given. This material was not contributed by the 59 working groups responsible for the applications and should not be 60 considered prescriptive for how the applications will meet their 61 authorization needs. Rather the intent is to explore the fundamental 62 needs of a variety of different applications with the view of 63 compiling a set of requirements that an authorization protocol will 64 need to meet in order to be generally useful. 66 Table of Contents 68 Status of this Memo ............................................ 1 69 Copyright Notice ............................................... 2 70 Abstract ....................................................... 2 71 1. Introduction ................................................ 3 72 2. PPP Dialin with Roaming ..................................... 4 73 2.1. Descriptive Model ...................................... 4 74 2.2. Authorization Requirements ............................. 6 75 3. Mobile-IP ................................................... 6 76 3.1. Relationship to the Framework .......................... 10 77 3.2. Minimized Internet Traversal ........................... 11 78 3.3. Key Distribution ....................................... 11 79 3.4. Mobile-IP Authorization Requirements ................... 12 80 4. Bandwidth Broker ............................................ 13 81 4.1. Model Description ...................................... 13 82 4.2. Components of the Two-Tier Model ....................... 14 83 4.3. Identification of Contractual Relationships ............ 14 84 4.3.1. Single-Domain Case .............................. 14 85 4.3.2. Multi-Domain Case ............................... 15 86 4.4. Identification of Trust Relationships .................. 16 87 4.5. Communication Models and Trust Relationships ........... 19 88 4.6. Bandwidth Broker Communication Models .................. 20 89 4.6.1. Concepts ........................................ 20 90 4.6.1.1. Intra-Domain Authorization ............... 20 91 4.6.1.2. Inter-Domain Authorization ............... 20 93 4.6.2. Bandwidth Broker Work Phases .................... 21 94 4.6.3. Inter-Domain Signaling .......................... 21 95 4.6.3.1. Phase 0 .................................. 21 96 4.6.3.2. Phase 1 .................................. 21 97 4.6.4. Bandwidth Broker Communication Architecture ..... 23 98 4.6.5. Two-Tier Inter-Domain Model ..................... 24 99 4.6.5.1. Session Initialization ................... 24 100 4.6.5.2. Service Setup ............................ 24 101 4.6.5.3. Service Cancellation ..................... 25 102 4.6.5.4. Service Renegotiation .................... 25 103 4.6.5.5. RAR and RAA .............................. 25 104 4.6.5.6. Session Maintenance ...................... 25 105 4.6.5.7. Intra-domain Interface Protocol .......... 25 106 4.7. Requirements ........................................... 25 107 5. Internet Printing ........................................... 26 108 5.1. Trust Relationships .................................... 27 109 5.2. Use of Attribute Certificates .......................... 28 110 5.3. IPP and the Authorization Descriptive Model ............ 29 111 6. Electronic Commerce ......................................... 30 112 6.1. Model Description ...................................... 31 113 6.1.1. Identification of Components .................... 31 114 6.1.2. Identification of Contractual Relationships ..... 32 115 6.1.3. Identification of Trust Relationships ........... 33 116 6.1.3.1. Static Trust Relationships ............... 33 117 6.1.3.2. Dynamic Trust Relationships .............. 36 118 6.1.4. Communication Model ............................. 36 119 6.2. Multi Domain Model ..................................... 38 120 6.3. Requirements ........................................... 39 121 7. Computer Based Education and Distance Learning .............. 41 122 7.1. Model Description ...................................... 41 123 7.1.1. Identification of Components .................... 42 124 7.1.2. Identification of Contractual Relationships ..... 42 125 7.1.3. Identification of Trust Relationships ........... 44 126 7.1.4. Sequence of Requests ............................ 45 127 7.2. Requirements ........................................... 47 128 8. Security Considerations ..................................... 48 129 Glossary ....................................................... 48 130 References ..................................................... 49 131 Authors' Addresses ............................................. 51 133 1. Introduction 135 This document is one of a series of three documents prepared by the 136 AAA WG authorization subgroup dealing with the authorization 137 requirements for AAA protocols. The three documents are: 139 AAA Authorization Framework [2] 140 AAA Authorization Requirements [3] 141 AAA Authorization Application Examples (this document) 143 In this memo, we examine several important Internet applications that 144 require authorization. For each application, we present a model 145 showing how it might do authorization and then map that model back to 146 the framework presented in [2]. We then present the authorization 147 requirements of the application as well as we presently understand 148 them. The requirements presented in this memo have been collected 149 together, generalized, and presented in [3]. 151 The intent of this memo is to validate and illustrate the framework 152 presented in [2] and to motivate the requirements presented in [3]. 153 This work is intended to be in alignment with the work of the various 154 working groups responsible for the authorization applications 155 illustrated. This memo should not, however, be regarded as 156 authoritative for any of the applications illustrated. Where 157 authoritative documents exist or are in development, they are listed 158 in the references at the end of this document. 160 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 161 negatives, in the way described in RFC 2119 [4]. 163 2. PPP Dialin with Roaming 165 In this section, we present an authorization model for dialin network 166 access in terms of the framework presented in [2]. Included in the 167 model are the multi-domain considerations required for roaming [5]. 168 Detailed requirements for network access protocols are presented in 169 [6]. 171 2.1. Descriptive Model 173 The PPP dialin application uses the pull sequence as discussed in 174 [2]. The roaming case uses the roaming pull sequence, also discussed 175 in [2]. This sequence is redrawn using dialin roaming terminology in 176 figure 1, below. 178 +------+ +-------------------------+ 179 | | | Home ISP | 180 | | | (User Home Organization)| 181 | | | +-------------------+ | 182 | | | | AAA Server | | 183 | | | | | | 184 | | | +-------------------+ | 185 | | | /|\ | | 186 | | +--------------+---+------+ 187 | | | | 188 | | |3 |4 189 | | | | 190 | | +--------------+---+------+ 191 | | | Visited ISP | | | 192 | | | | \|/ | 193 | User | | +-------------------+ | 194 | | | | AAA Server | | 195 | | | | | | 196 | | | +-------------------+ | 197 | | | /|\ | | 198 | | | |2 |5 | 199 | | | | \|/ | 200 | | 1 | +-------------------+ | 201 | |------+->| NAS (Service | | 202 | |<-----+--| Equipment) | | 203 | | 6 | +-------------------+ | 204 | | | (Service Provider) | 205 +------+ PPP +-------------------------+ 207 Fig. 1 -- Dialin Authorization 208 Based on Roaming Pull Sequence 210 In this model, the User dials in to a Network Access Server (NAS) 211 provided by the visited (or foreign) ISP (the Service Provider in the 212 general model). The User is authenticated using a protocol such as 213 PAP, CHAP, or EAP which is encapsulated in PPP frames (1). Because 214 the User has not yet gained access to the network, he or she cannot 215 send IP datagrams to a AAA server. At this point, the User can only 216 communicate with the NAS (Service Equipment). The NAS forwards the 217 User's authentication/ authorization request including the Network 218 Access Identifier (NAI) [7] to a AAA server in its own domain via 219 RADIUS [8] or a successor AAA protocol (2). The visited ISP's AAA 220 server examines the realm from the NAI and forwards the request to 221 the User's home domain AAA server (3). The home domain AAA server 222 authenticates the user and authorizes access according to a roaming 223 agreement. The home domain AAA server may return service parameters 224 (e.g. Idle-Timeout) to the visited ISP's AAA server (4) which 225 forwards them to the NAS, possibly adding additional service 226 parameters (5). The NAS completes PPP session initialization (6). 228 In the future, this model may be expanded in several ways [9]. For 229 instance, Authentication and Authorization may be done in separate 230 passes using different servers in order to support specialized forms 231 of authentication. Or to better support roaming, a broker may be 232 inserted between the visited ISP and the home ISP. Or authorization 233 may be supported based on other identifiers such as the caller ID and 234 called ID obtained from the PSTN (e.g., using ANI and DNIS). 236 2.2. Authorization Requirements 238 The following requirements are identified in [9] for authorizing PPP 239 dialin service using roaming. 241 - Authorization separate from authentication should be allowed when 242 necessary, but the AAA protocol MUST allow for a single message to 243 request both authentication and authorization. 245 - The AAA protocol MUST be "proxyable", meaning that a AAA Server or 246 PDP MUST be able to forward the request to another AAA Server or 247 PDP, which may or may not be within the same administrative 248 domain. 250 - The AAA protocol MUST allow for intermediate brokers to add their 251 own local Authorization information to a request or response. 253 - When a broker is involved, the protocol MUST provide end to end 254 security. 256 - The broker MUST be able to return a forwarding address to a 257 requester, allowing two nodes to communicate together. 259 - The protocol MUST provide the following features (per user 260 session): 261 1. One Authentication, One Authorization 262 2. One Authentication, Multiple Authorization 263 3. Multiple Authentication, Multiple Authorization 265 3. Mobile-IP 267 The Mobile-IP protocol is used to manage mobility of an IP host 268 across IP subnets [10]. Recent activity within the Mobile-IP Working 269 Group has defined the interaction between Mobile-IP and AAA in order 270 to provide: 272 - Better scaling of security associations 273 - Mobility across administrative domain boundaries 274 - Dynamic assignment of Home Agent 276 The Mobile IP protocol, as defined in [10], works well when all 277 mobile nodes belong to the same administrative domain. Some of the 278 current work within the Mobile IP Working Group is to allow Mobile IP 279 to scale across administrative domains. This changes the trust model 280 that is currently defined in [10]. 282 The requirements for Mobile-IP authorization are documented in [11]. 283 In this section, we develop a multi-domain model for Mobile-IP 284 authorization and present it in the terms of the framework presented 285 in [2]. 287 Figure 2 depicts the new AAA trust model for Mobile-IP. In this 288 model each network contains mobile nodes (MN) and a AAA server (AAA). 289 Each mobility device shares a security association (SA) with the AAA 290 server within its own home network. This means that none of the 291 mobility devices initially share a security association. Both 292 administrative domains' AAA servers can either share a security 293 association, or can have a security association with an intermediate 294 broker. 296 Broker AAA 297 +--------+ 298 | | 299 | AAA | 300 /=====| |=====\ 301 // +--------+ \\ 302 Foreign // SA SA \\ Home 303 AAA // \\ AAA 304 +--------+ +--------+ 305 | | SA | | 306 | AAA |======================| AAA | 307 | | (in lieu of broker) | | 308 +--------+ +--------+ 309 || || || 310 || || || 311 SA || SA || || SA 312 || || || 313 || || || 314 +---------+ +---------+ +---------+ 315 | | | | | | 316 | FA | | HA | | MN | 317 | | | | | | 318 +---------+ +---------+ +---------+ 320 Fig. 2 -- Mobile-IP AAA Trust Model 322 Figure 3 provides an example of a Mobile-IP network that includes 323 AAA. In the integrated Mobile-IP/AAA Network, it is assumed that each 324 mobility agent shares a security association between itself and its 325 local AAA server. Further, the Home and Foreign AAA servers both 326 share a security association with the broker's AAA server. Lastly, 327 it is assumed that each mobile node shares a trust relationship with 328 its home AAA Server. 330 Visited Access Broker Home IP 331 Provider Network Network Network 332 +--------+ +--------+ +--------+ 333 | | | | | | 334 | AAA |------| AAA |------| AAA | 335 | | | | | | 336 +--------+ +--------+ +--------+ 337 | | 338 | | 339 AAA | | AAA 340 | | 341 | | 342 +---------+ +---------+ 343 | | | | 344 | FA | | HA | 345 | | | | 346 +---------+ +---------+ 347 | 348 | Visited Access Home Network 349 | Provider Network -Private Network 350 Mobile | -Home Provider 351 IP | -Home ISP 352 | 353 +--------+ 354 | Mobile | 355 | Node | 356 +--------+ 358 Fig. 3 -- General Wireless IP Architecture for Mobile-IP AAA 360 In this example, a Mobile Node appears within a foreign network and 361 issues a registration to the Foreign Agent. Since the Foreign Agent 362 does not share any security association with the Home Agent, it sends 363 a AAA request to its local AAA server, which includes the 364 authentication information and the Mobile-IP registration request. 365 The Mobile Node cannot communicate directly with the home AAA Server 366 for two reasons: 368 - It does not have access to the network. The registration request 369 is sent by the Mobile Node to request access to the network. 370 - The Mobile Node may not have an IP address, and may be requesting 371 that one be assigned to it by its home provider. 373 The Foreign AAA Server will determine whether the request can be 374 satisfied locally through the use of the Network Access Identifier 375 [7] provided by the Mobile Node. The NAI has the format of 376 user@realm and the AAA Server uses the realm portion of the NAI to 377 identify the Mobile Node's home AAA Server. If the Foreign AAA Server 378 does not share any security association with the Mobile Node's home 379 AAA Server, it may forward the request to its broker. If the broker 380 has a relationship with the home network, it can forward the request, 381 otherwise a failed response is sent back to the Foreign AAA Server. 383 When the home AAA Server receives the AAA Request, it authenticates 384 the user and begins the authorization phase. The authorization phase 385 includes the generation of: 387 - Dynamic Session Keys to be distributed among all Mobility Agents 388 - Optional Dynamic assignment of a Home Agent 389 - Optional Dynamic assignment of a Home Address (note this could be 390 done by the Home Agent). 391 - Optional Assignment of QOS parameters for the Mobile Node [12] 393 Once authorization is complete, the home AAA Server issues an 394 unsolicited AAA request to the Home Agent, which includes the 395 information in the original AAA request as well as the authorization 396 information generated by the home AAA server. The Home Agent 397 retrieves the Registration Request from the AAA request and processes 398 it, then generates a Registration Reply that is sent back to the home 399 AAA server in a AAA response. The message is forwarded through the 400 broker back to the Foreign AAA server, and finally to the Foreign 401 Agent. 403 The AAA servers maintain session state information based on the 404 authorization information. If a Mobile Node moves to another Foreign 405 Agent within the foreign domain, a request to the foreign AAA server 406 can immediately be done in order to immediately return the keys that 407 were issued to the previous Foreign Agent. This minimizes an 408 additional round trip through the internet when micro mobility is 409 involved, and enables smooth hand-off. 411 3.1. Relationship to the Framework 413 Mobile-IP uses the roaming pull model described in [2]. The Mobile 414 Node is the User. The Foreign Network is the Service Provider with 415 the Foreign Agent as the Service Equipment. The Home Network is the 416 User Home Organization. Note that the User Home Organization 417 operates not only a AAA Server, but also the Home Agent. Note, also, 418 that a broker has been inserted between the Service Provider and the 419 User Home Organization. 421 3.2. Minimized Internet Traversal 423 Although it would have been possible for the AAA interactions to be 424 performed for basic authentication and authorization, and the 425 Registration flow to be sent directly to the Home Agent from the 426 Foreign Agent, one of the key Mobile-IP AAA requirements is to 427 minimize Internet Traversals. Including the Registration Request and 428 Replies in the AAA messages allows for a single traversal to 429 authenticate the user, perform authorization and process the 430 Registration Request. This streamlined approach is required in order 431 to minimize the latency involved in getting wireless (cellular) 432 devices access to the network. New registrations should not increase 433 the connect time more than what the current cellular networks 434 provide. 436 3.3. Key Distribution 438 In order to allow the scaling of wireless data access across 439 administrative domains, it is necessary to minimize the security 440 associations required. This means that each Foreign Agent does not 441 share a security association with each Home Agent on the Internet. 442 The Mobility Agents share a security association with their local AAA 443 server, which in turn shares a security association with other AAA 444 servers. Again, the use of brokers, as defined by the Roaming 445 Operations (roamops) Working Group, allows such services to scale by 446 allowing the number of relationships established by the providers to 447 be reduced. 449 After a Mobile Node is authenticated, the authorization phase 450 includes the generation of Sessions Keys. Specifically, three keys 451 are generated: 453 - k1 - Key to be shared between the Mobile Node and the Home Agent 454 - k2 - Key to be shared between the Mobile Node and the Foreign 455 Agent 456 - k3 - Key to be shared between the Foreign Agent and the Home 457 Agent 459 Each Key is propagated to each mobility device through the AAA 460 protocol (for the Foreign and Home Agent) and via Mobile-IP for the 461 Mobile Node (since the Mobile Node does not interface directly with 462 the AAA servers). 464 Figure 4 depicts the new security associations used for Mobile-IP 465 message integrity using the keys derived by the AAA server. 467 +--------+ +--------+ 468 | | k3 | | 469 | FA |======================| HA | 470 | | | | 471 +--------+ +--------+ 472 \\ // 473 \\ k2 k1 // 474 \\ +--------+ // 475 \\ | | // 476 \=====| MN |=====/ 477 | | 478 +--------+ 480 Fig. 4 -- Security Association after Key Distribution 482 Once the session keys have been established and propagated, the 483 mobility devices can exchange registration information directly 484 without the need of the AAA infrastructure. However the session keys 485 have a lifetime, after which the AAA infrastructure must be used in 486 order to acquire new session keys. 488 3.4. Mobile-IP Authorization Requirements 490 To summarize, Mobile-IP has the following authorization requirements: 492 1. Mobile-IP requires an AAA protocol that makes use of the pull 493 model. 495 2. Mobile-IP requires broker support, and data objects must contain 496 data integrity and confidentiality end-to-end. This means that 497 neither the broker nor any other intermediate AAA node should be 498 able to decrypt the data objects, but they must be able to verify 499 the objects' validity. 501 3. Authorization includes Resource Management. This allows the AAA 502 servers to maintain a snapshot of a mobile node's current 503 location, keying information, etc. 505 4. Due to the nature of the service being offered, it is imperative 506 that the AAA transaction add minimal latency to the connect time. 507 Ideally, the AAA protocol should allow for a single round trip for 508 authentication and authorization. 510 5. If the AAA protocol allows for the Mobile-IP registration messages 511 to be embedded within the authentication/authorization request, 512 this will further reduce the number of round trips required and 513 hence reduce the connect time. 515 6. It must be possible to pass Mobile-IP specific key management data 516 along with the authorization data. This allows the AAA server to 517 act as a Key Distribution Center (KDC). 519 7. It must be possible to pass other application-specific data units 520 such as home agent selection and home address assignment to be 521 carried along with the authorization data units. 523 8. The authorization response should allow for diffserv (QOS) 524 profiles, which can be used by the mobility agents to provide some 525 quality of service to the mobile node. 527 9. The AAA protocol must allow for unsolicited messages to be sent to 528 a "client", such as the AAA client running on the Home Agent. 530 4. Bandwidth Broker 532 This section describes authorization aspects derived from the 533 Bandwidth Broker architecture as discussed within the Internet2 Qbone 534 BB Advisory Council. We use authorization model concepts to identify 535 contract relationships and trust relationships, and we present 536 possible message exchanges. We will derive a set of authorization 537 requirements for Bandwidth Brokers from our architectural model. The 538 Internet 2 Qbone BB Advisory Council researches a single and multi- 539 domain implementation based on 2-tier authorization concepts. A 3- 540 tier model is considered as a future work item and therefore not part 541 of this description. Information concerning the Internet 2 Bandwidth 542 Broker work and its concepts can be found at: 544 http://www.merit.edu/working.groups/i2-qbone-bb 546 The material in this section is based on [13] which is a work in 547 progress of the Internet2 Qbone BB Advisory Council. 549 4.1. Model Description 551 The establishment of a model involves four steps: 553 1. identification of the components that are involved and what 554 they are called in this specific environment, 555 2. identification of the relationships between the involved parties 556 that are based on some form of agreement, 557 3. identification of the relationships that are based on trust, and 558 4. consideration of the sequence of messages exchanged between 559 components. 561 4.2. Components of the Two-Tier Model for Bandwidth Brokerage 563 We will consider the components of a bandwidth broker transaction in 564 the context of the conceptual entities defined in [2]. The bandwidth 565 broker two-tier model recognizes a User and the Service Provider 566 controlling the Service Equipment. 568 The components are as follows: 570 - The Service User (User) -- A person or process willing to use 571 certain level of QoS by requesting the allocation of a 572 quantifiable amount of resource between a selected destination and 573 itself. In bandwidth broker terms, the User is called a Service 574 User, capable of generating a Resource Allocation Request (RAR). 576 - The Bandwidth Broker (Service Provider) -- a function that 577 authorizes allocation of a specified amount of bandwidth resource 578 between an identified source and destination based on a set of 579 policies. In this context we refer to this function as the 580 Bandwidth Broker. A Bandwidth Broker is capable of managing the 581 resource availability within a network domain it controls. 583 Note: a 3-tier model involving a User Home Organization is recognized 584 in [13], however its development is left for future study and 585 therefore it is not discussed in this document. 587 4.3. Identification of Contractual Relationships 589 Authorizations to obtain bandwidth are based on contractual 590 relationships. In both the single and muli-domain cases, the current 591 Bandwidth Broker model assumes that a User always has a contractual 592 relationship with the service domain to which it is connected. 594 4.3.1. Single-Domain Case 596 In the single-domain case, the User has a contract with a single 597 Service Provider in a single service domain. 599 +-------------+ 600 | | 601 | +---------+ | 602 | |Bandwidth| | 603 +-------+ | |Broker | | 604 | | | | | | 605 |Service| | +---------+ | 606 |User |=========| | 607 | | | +---------+ | 608 | | | | Network | | 609 +-------+ | | Routing | | 610 | | Devices | | 611 | +---------+ | 612 | Autonomous | 613 | Service | 614 | Domain | 615 +-------------+ 616 ==== contractual 617 relationship 619 Fig. 5 -- Two-Tier Single Domain Contractual Relationships 621 4.3.2. Multi-Domain Case 623 In the multi-domain case, the User has a contract with a single 624 Service Provider. This Service Provider has a contract with 625 neighboring Service Providers. This model is used when independent 626 autonomous networks establish contracts with each other. 628 +-------------+ +-------------+ 629 | | | | 630 | +---------+ | | +---------+ | 631 | |Bandwidth| | | |Bandwidth| | 632 +-------+ | |Broker | | | |Broker | | 633 | | | | | | | | | | 634 |Service| | +---------+ | | +---------+ | 635 |User |=========| |========| | 636 | | | +---------+ | | +---------+ | 637 | | | | Network | | | | Network | | 638 +-------+ | | Routing | | | | Routing | | 639 | | Devices | | | | Devices | | 640 | +---------+ | | +---------+ | 641 | Autonomous | | Autonomous | 642 | Service | | Service | 643 | Domain A | | Domain B | 644 +-------------+ +-------------+ 646 ==== contractual 647 relationship 649 Fig. 6 -- Two-Tier Multi-Domain Contractual Relationships 651 4.4. Identification of Trust Relationships 653 Contractual relationships may be independent of how trust, which is 654 necessary to facilitate authenticated and possibly secure 655 communication, is implemented. There are several alternatives in the 656 Bandwidth Broker environment to create trusted relationships. 657 Figures 7 and 8 show two alternatives that are options in the two- 658 tier Bandwidth Broker model. 660 +-------------+ +-------------+ 661 | | | | 662 | +---------+ | | +---------+ | 663 | |Bandwidth| | | |Bandwidth| | 664 +-------+ | |Broker | | | |Broker | | 665 | O***********O O************O | | 666 |Service| | +----O----+ | | +----O----+ | 667 |User |=========| * |========| * | 668 | | | +----0----+ | | +----O----+ | 669 | | | |Network | | | |Network | | 670 +-------+ | |Routing | | | |Routing | | 671 | |Devices | | | |Devices | | 672 | +---------+ | | +---------+ | 673 | Autonomous | | Autonomous | 674 | Service | | Service | 675 | Domain A | | Domain B | 676 +-------------+ +-------------+ 678 ==== contractual relationship 679 O**O trust relationship 681 Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1 682 +-------------+ +-------------+ 683 | | | | 684 | +---------+ | | +---------+ | 685 | |Bandwidth| | | |Bandwidth| | 686 +-------+ | |Broker | | | |Broker | | 687 | | | | | | | | | | 688 |Service| | +----O----+ | | +----O----+ | 689 |User |=========| * |========| * | 690 | | | +----O----+ | | +----O----+ | 691 | O***********O Network O************O Network | | 692 +-------+ | | Routing | | | | Routing | | 693 | | Devices | | | | Devices | | 694 | +---------+ | | +---------+ | 695 | Autonomous | | Autonomous | 696 | Service | | Service | 697 | Domain A | | Domain B | 698 +-------------+ +-------------+ 700 ==== contractual relationship 701 O**O trust relationship 703 Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2 705 Although [13] does not recommend specifics regarding this question, 706 the document recognizes the need for trust relationships. In the 707 first model, a trust relationship, based on some form of 708 authentication method, is created between the User and the Bandwidth 709 Broker and among Bandwidth Brokers. In the second model, which 710 enjoys some popularity in enterprise networks, the trust relationship 711 may be established via the wiring closet and the knowledge of which 712 physical router port or MAC address is connected to which user. The 713 router-Bandwidth Broker relationship may be established physically or 714 by some other authentication method or secure channel. 716 A Certificate Authority (CA) based trust relationship is shown in 717 figure 9. In this figure, a CA signs public key certificates, which 718 then can be used in encrypted message exchanges using public keys 719 that are trusted by all involved. As a first step, each involved 720 party must register with the CA so it can join a trust domain. The 721 Router-Bandwidth Broker relationship may be established as described 722 in the two previous figures. An interesting observation regarding 723 this kind of model is that the bandwidth broker in domain B may route 724 information to the user via the bandwidth broker in domain A without 725 BB1 being able to read the information (using end-to-end security). 726 This model creates a meshed trust relationship via a tree like CA 727 structure. 729 +-------------------+ 730 | Certificate | 731 ....................| Authority | 732 : ..| |.. 733 : : +-------------------+ : 734 : : : 735 : : : 736 : ***************:*********************** : 737 : * +---:---------+ +---*--:------+ 738 : * | : | | * : | 739 : * | +-:-------+ | | +-O--:----+ | 740 : * | |{C} | | | | {C} | | 741 +---:--O+ | |Bandwidth| | | |Bandwidth| | 742 | {C} O***********O Broker O************O Broker | | 743 |Service| | +----O----+ | | +----O----+ | 744 |User |=========| * |========| * | 745 | | | +----0----+ | | +----O----+ | 746 | | | |Network | | | |Network | | 747 +-------+ | |Routing | | | |Routing | | 748 | |Devices | | | |Devices | | 749 | +---------+ | | +---------+ | 750 | Autonomous | | Autonomous | 751 | Service | | Service | 752 | Domain A | | Domain B | 753 +-------------+ +-------------+ 755 ==== contractual relationship 756 O**O trust relationship 757 {C}. certification process 759 Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 3 761 4.5. Communication Models and Trust Relationships 763 When describing the Bandwidth Broker communication model, it is 764 important to recognize that trust relationships between components 765 must ensure secure and authenticated communication between the 766 involved components. As the Internet 2 Qbone Bandwidth Broker work 767 does not recommend any particular trust relationship model, we make 768 the same assumptions as [13]. In theory, the trust model and 769 communication model can be independent, however communication 770 efficiency will determine the most logical approach. 772 4.6. Bandwidth Broker Communication Models 774 4.6.1. Concepts 776 The current Internet 2 Qbone Bandwidth Broker discussion describes a 777 two-tier model, where a Bandwidth Broker accepts Resource Allocation 778 Requests (RAR's) from users belonging to its domain or RAR's 779 generated by upstream Bandwidth Brokers from adjacent domains. Each 780 Bandwidth Broker will manage one service domain and subsequently 781 provide authorization based on a policy that decides whether a 782 request can be honored. 784 4.6.1.1. Intra-Domain Authorization 786 Admission Authorization or Connection Admission Control (CAC) for 787 intra-domain communication is performed using whatever method is 788 appropriate for determining availability of resources within the 789 domain. Generally a Bandwidth Broker configures its service domain to 790 certain levels of service. RAR's are subsequently accommodated using 791 a policy-based decision. 793 4.6.1.2. Inter-Domain Authorization 795 Service Level Specifications (SLS's) provide the basis for handling 796 inter-domain bandwidth authorization requests. A Bandwidth Broker 797 monitors both the state of its network components and the state of 798 its connections to neighboring networks. SLS's are translations of 799 SLA's established between Autonomous Service Domains. Each Bandwidth 800 Broker will initialize itself so it is aware of existing SLS's. 801 SLS's are established in a unidirectional sense. Two SLS's must 802 govern a bi-directional connection. SLS's are established on the 803 level of aggregate data-flows and the resources (bandwidth) 804 provisioned for these flows. 806 A Bandwidth Broker may honor an inter-domain RAR by applying policy 807 decisions determining that a particular RAR does fit into a pre- 808 established SLS. If successful, the Bandwidth Broker will authorize 809 the usage of the bandwidth. If unsuccessful, the Bandwidth Broker 810 may deny the request or approve the request after it has re- 811 negotiated the SLS with its downstream Bandwidth Broker. 813 A separate Policy Manager may be involved in the CAC decision. The 814 Internet 2 Qbone Bandwidth Broker discussion recognizes an ideal 815 environment where Bandwidth Brokers and Policy Managers work together 816 to provide CAC using integrated policy services [13]. 818 4.6.2. Bandwidth Broker Work Phases 820 The Internet 2 Qbone Bandwidth Broker discussion proposes development 821 of the Bandwidth Broker model in several phases: 823 - Phase 0: Local Admission. RAR's are only handled within a local 824 domain. SLS's are pre-established using manual methods (fax, e- 825 mail). 827 - Phase 1: Informed Admission. RAR's spanning multiple domains are 828 authorized based on information obtained from one or more 829 Bandwidth Brokers along the path. 831 - Phase 2: Dynamic SLS admission. Bandwidth Brokers can dynamically 832 set up new SLS's. 834 Although the local admission case is addressed, the current Internet 835 2 Qbone Bandwidth Broker work is currently concerned with solving 836 multi-domain problems in order to allow individual Bandwidth Brokers 837 to inter-operate as identified in phase 0 or 1. 839 4.6.3. Inter-Domain Signaling 841 4.6.3.1. Phase 0 843 In phase 0 implementations, no electronic signaling between Bandwidth 844 Brokers is performed and SLS negotiation will be performed manually 845 (phone, email etc) by network operators. An RAR is only handled 846 within the domain and may originate from a User or ingress router. 848 4.6.3.2. Phase 1 850 Here a CAC decision is made on information obtained from downstream 851 Bandwidth Brokers. This information could come from the next hop 852 Bandwidth Broker or all Bandwidth Brokers downstream to the 853 destination. 855 Two fundamental signaling approaches between Bandwidth Brokers have 856 been identified for the Informed Admission case. These are 857 illustrated in figure 10. 859 +-------+ +-------+ +-------+ +-------+ 860 | | | | | | | | 861 | |RAR | | 1 | | 2 | | 862 | User |-------->| |-------->| |-------->| | 863 | | RAA | BB1 | 4 | BB2 | 3 | BB3 | 864 | |<--------| |<--------| |<--------| | 865 | | | | | | | | 866 | | | | | | | | 867 +-------+ +-------+ +-------+ +-------+ 869 A)End-to-end signaling 871 +-------+ +-------+ +-------+ +-------+ 872 | | | | | | | | 873 | |RAR | | 1 | | 3 | | 874 | User |-------->| |-------->| |-------->| | 875 | | RAA | BB1 | 2 | BB2 | 4 | BB3 | 876 | |<--------| |<--------| |<--------| | 877 | | 7 | | 6 | | 5 | | 878 | |<--------| |<--------| |<--------| | 879 +-------+ +-------+ +-------+ +-------+ 881 B) Immediate response signaling. 883 Fig. 10 -- Fundamental Signalling Approaches 885 - End to End signaling. An RAR from a User to BB1 is forwarded to 886 BB2 (1). BB2 will forward the request to BB3 (2). If BB3 is the 887 destination of the request, BB3 will authorize the request and 888 reply to BB2 (3). BB2 will then reply to BB1 (4), and BB1 will 889 send a Resource Allocation Answer (RAA) back to the User to 890 complete the authorization. 892 - Immediate response signaling. This is the case where BB1 will 893 want to authorize an RAR from its domain and forwards the 894 authorization request to BB2 (1). If BB2 approves, the response 895 is immediately returned to BB1 (2). BB1 will send an RAA back to 896 the User. If the authorization was positive BB2 will forward 897 subsequently a request to the next BB, BB3 (3). BB3 authorizes 898 the request and responds to BB2 (4). If the response is negative 899 (5), BB2 will cancel the authorization it previously issued to BB1 900 (6) and this will result in a cancellation from BB1 to the user 901 (7). In this case the RAA authorization is valid until revoked by 902 7. 904 4.6.4. Bandwidth Broker Communication Architecture 906 Figure 11 shows components of the discussed Bandwidth Broker 907 architecture with its interfaces. 909 - An intra-domain interface allows communication with all the 910 service components within the network that the Bandwidth Broker 911 controls. 913 - An inter-domain interface allows communication between Bandwidth 914 Brokers of different autonomous networks. 916 - A user/application interface allows the Bandwidth Broker to be 917 managed manually. Requests can be sent from the User or a host 918 application. 920 - A policy manager interface allows implementation of complex policy 921 management or admission control. 923 - A routing table interface allows the Bandwidth Broker to 924 understand the network topology. 926 - An NMS interface allows coordination of network provisioning and 927 monitoring. 929 adjacent BB <---------------------------> adjacent BB 930 | 931 V 932 +------------------------------+ 933 | | inter-domain | | 934 | -------------- ------| 935 application | | PM | 936 server \ | |iface | 937 \ |------- ---------+ ------| 938 ->| user/ | | simple | ------| 939 user/host-->| app | | policy | | NMS | 940 ->| iface | | services| |iface | 941 / |------- ---------+ ------| 942 network / | | 943 operator | ------- ------- | 944 | | data | |routing| | 945 | | store | |info | | 946 | | | | | | 947 | ------- ------- | 948 | | 949 | ---------------- | 950 | | intra-domain | | 951 +------------------------------+ 952 ^ 953 | 954 edge router(s) <---------------------------> edge router(s) 956 Fig. 11 -- Bandwidth Broker Architecture 958 4.6.5. Two-Tier Inter-Domain Bandwidth Broker Communication Model 960 4.6.5.1. Session Initialization 962 Before Bandwidth Brokers can configure services between two adjacent 963 domains, they have to establish and initialize a relationship. No 964 authentication is used; therefore any trust relationship is implicit. 965 Part of the initialization is an exchange of topology information 966 (list of adjacent Bandwidth Brokers). 968 4.6.5.2. Service Setup 970 The Bandwidth Broker must first be configured in regard to agreed 971 bi-lateral service levels. All resources allocated to a particular 972 level of provisioned service must be reserved in each domain. 974 A Service Setup Request (SSR) is generated (on demand by the 975 operator or at startup of the system) and forwarded to a downstream 976 Bandwidth Broker. The downstream Bandwidth Broker will check the 977 consistency with its own service level specifications and respond 978 with Setup Answer message (SA) agreements. This message exchange 979 confirms and identifies pre-established service authorization levels. 981 4.6.5.3. Service Cancellation 983 A Service Cancellation (SC) message may cancel a service 984 authorization. This message may be initiated by the operator or by an 985 expiration date. A Cancellation Answer (CA) is returned. 987 4.6.5.4. Service Renegotiation 989 An (optional) Service-Renegotiation message (SR) may allow a 990 Bandwidth Broker to re-negotiate an existing service. This message 991 may be initiated by the operator or automatically when a certain 992 threshold is reached. Renegotiations happen within the margins of a 993 pre-established authorization. 995 4.6.5.5. Resource Allocation Request and Resource Allocation Answer 997 An RAR allocates a requested level of service on behalf of the User 998 and when available it will decide on the admittance of a certain User 999 to the service. A Bandwidth Broker may receive an RAR via either the 1000 intra-domain or inter-domain interface. The RAR must refer to the 1001 Service SetUp Identification (SSU_ID), which binds a request to a 1002 certain authorization. A Resource Allocation Answer (RAA) confirms or 1003 rejects a request or it may indicate an "in progress" state. 1005 4.6.5.6. Session Maintenance 1007 A certain level of session maintenance is required to keep Bandwidth 1008 Brokers aware of each other. This must be implemented using time- 1009 outs and keep-alive messages. This will help Bandwidth Brokers to 1010 notice when other Bandwidth Brokers disappear. 1012 4.6.5.7. Intra-domain Interface Protocol 1014 The Intra-domain interface protocol used between a Bandwidth Broker 1015 and the routers it controls may be COPS, SNMP, or Telnet Command Line 1016 Interface. 1018 4.7. Requirements 1020 From the above descriptions we derive the following requirements. 1022 - The Authorization mechanism may require trust relationships to be 1023 established before any requests can be made from the User to the 1024 Service Provider. Currently trust relationship establishment is 1025 implicit. 1027 - A confirmation of authorization is required in order to initialize 1028 the system. 1030 - A negation of static authorization is required to shut down 1031 certain services. 1033 - A renegotiation of static authorization is required to alter 1034 services (SLS's). 1036 - Dynamic authorization requests (RAR) must fit into pre-established 1037 static authorizations (SLS's). 1039 - Dynamic authorization requests (RAR) may be answered by an "in 1040 progress state" answer. 1042 - Provisions must be made to allow reconstruction of authorization 1043 states after a Bandwidth Broker re-initializes. 1045 5. Internet Printing 1047 The Internet Printing Protocol, IPP [14], has some potentially 1048 complex authorization requirements, in particular with the "print- 1049 by-reference" model. The following attempts to describe some 1050 possible ways in which an authorization solution for this aspect of 1051 IPP might work, and to relate these to the framework described in 1052 [2]. This is not a product of the IPP working group, and is meant 1053 only to illustrate some issues in authorization in order to establish 1054 requirements for a "generic" protocol to support AAA functions across 1055 many applications. 1057 IPP print-by-reference allows a user to request a print service to 1058 print a particular file. The user creates a request to print a 1059 particular file on a printer (or one of a group of printers). The 1060 key aspect is that the request includes only the file name and not 1061 the file content. The print service must then read the file from a 1062 file server prior to printing. Both the file server and the print 1063 server must authorize the request. Once initiated, printing will be 1064 done without intervention of the user; i.e., the file will be sent 1065 directly to the print service rather than through the user to the 1066 printer. 1068 5.1. Trust Relationships 1070 The assumption is that the Printer and File Server may be owned and 1071 operated by different organizations. There appear to be two models 1072 for how "agreements" can be set up. 1074 1. User has agreement with Print Server; Print Server has agreement 1075 with File Server. 1077 2. User has agreements with both File and Print Server directly. 1079 In case 1, the user has a trust relationship with the Print Service 1080 AAA Server. The Printer forwards the request to the File Server. The 1081 File Server authorizes the Printer and determines if the Printer is 1082 allowed access to the file. Note that while there may be some cases 1083 where a Print Server may on its own be allowed access to files 1084 (perhaps some "public files", or that can only be printed on certain 1085 "secure" printers), it is normally the case that files are associated 1086 with users and not with printers. This is not a good "generic" model 1087 as it tends to make the print service an attractive point of attack. 1089 +------+ +----------------------+ 1090 | | | File Service |----+ 1091 | | | AAA Server |<-+ | 1092 | | +----------------------+ | | 1093 | | | | | | 1094 | | | File Server | | | 1095 | | | | | | 1096 | User | +----------------------+ | | 1097 | | | | 1098 | | | | 1099 | | | | 1100 | | +----------------------+ | | 1101 | |------>| Print Service |--+ | 1102 | |<------| AAA Server |<---+ 1103 | | +----------------------+ 1104 | | | Print Server | 1105 | | | and Printer | 1106 +------+ +----------------------+ 1108 Fig. 12 -- Case 1 1109 User authorizes with Print Service. 1110 Printer authorizes with File Service. 1112 In case 2, the user must have a trust relationship with both the file 1113 and print services so that each can verify the service appropriate to 1114 the User. In this case, the User first contacts the File Service AAA 1115 Server and requests that it enable authorization for the Print 1116 Service to access the file. This might be done in various ways, for 1117 example the File Service AAA Server may return a token to the User 1118 which can (via the Print Service) be presented to the File Server to 1119 enable access. 1121 +------+ +----------------------+ 1122 | |------>| File Service | 1123 | |<------| AAA Server | 1124 | | +----------------------+ 1125 | | 1126 | | +----------------------+ 1127 | | | File Server | 1128 | User | +----------------------+ 1129 | | /|\ | 1130 | | | | 1131 | | | \|/ 1132 | | +----------------------+ 1133 | |------>| Print Service | 1134 | |<------| AAA Server | 1135 | | +----------------------+ 1136 | | | Print Server | 1137 | | | and Printer | 1138 +------+ +----------------------+ 1140 Fig. 13 -- Case 2 1141 User authorizes File and Print Service. 1142 Must create binding for session between 1143 Print Service and File Service. 1145 5.2. Use of Attribute Certificates in Print-by-Reference 1147 The print-by-reference case provides a good example of the use of 1148 attribute certificates as discussed in [2]. If we describe case 2 1149 above in terms of attribute certificates (ACs) we get the diagram 1150 shown in figure 14. 1152 +------+ +----------------------+ 1153 | |------>| File Service | 1154 | |<------| AAA Server | 1155 | |Get AC +----------------------+ 1156 | | 1157 | | +----------------------+ 1158 | | | File Server |----+ 1159 | | | |<-+ | 1160 | User | +----------------------+ | | 1161 | | | | 1162 | | +---authorize passing AC | |<---Create session 1163 | | | | | Using AC 1164 | | V +----------------------+ | | 1165 | |------>| Print Service | | | 1166 | |<------| AAA Server | | | 1167 | | +----------------------+ | | 1168 | | | Print Server |--+ | 1169 | | | and Printer |<---+ 1170 +------+ +----------------------+ 1172 Fig. 14 -- Using Attribute Certificates in IPP Authorization 1174 In this case, the User gets an AC from the File Service's AAA Server 1175 which is signed by the File Service AAA Server and contains a set of 1176 attributes describing what the holder of the AC is allowed to do. The 1177 User then authorizes with the Print Service AAA Server and passes the 1178 AC in the authorization request. The Printer establishes a session 1179 with the File Server, passing it the AC. The File Server trusts the 1180 AC because it is signed by the File Service AAA Server and allows (or 1181 disallows) the session. 1183 It is interesting to note that an AC could also be created and signed 1184 by the User, and passed from the Print Server to the File Server. The 1185 File Server would need to be able to recognize the User's signature. 1186 Yet another possibility is that the Print Service AAA Server could 1187 simply authenticate the User and then request an AC from the File 1188 Service AAA Server. 1190 5.3. IPP and the Authorization Descriptive Model 1192 The descriptive model presented in [2] includes four basic elements: 1193 User, User Home Organization, Service Provider AAA Server, and 1194 Service Equipment. 1196 Mapping these to IPP, the User is the same, the User Home 1197 Organization (if included) is the same. The Service Provider AAA 1198 Server and the Service Equipment are expected to be closely coupled 1199 on the same processor. In other words, the interface between the 1200 Print Service AAA Server and the Printer as well as that between the 1201 File Service AAA Server and the File Server is an internal one that 1202 will not require a formal protocol (although some standard API might 1203 be useful). 1205 The concept of a Resource Manager (see [2]) has some interesting 1206 twists relative to IPP. Once started, the user is not involved in 1207 the service, but until printing is complete it seems useful that any 1208 of the parties in the authorization process be allowed to query for 1209 status or to cancel the print session. The user needs a way to 1210 "bind" to a particular session, and may have to reauthorize to be 1211 allowed to access Resource Manager information. 1213 6. Electronic Commerce 1215 This section describes the authorization aspects of an e-commerce 1216 architecture typically used in Europe. We will use this model to 1217 identify contractual and trust relationships and message exchanges. 1218 We will then identify a set of authorization requirements for e- 1219 commerce. 1221 Whereas most e-commerce protocols focus on authentication and message 1222 integrity, e-commerce exchanges as described by the Internet Open 1223 Trading Protocol (trade) Working Group in [15] also involve 1224 authorization. This section will examine one e-commerce protocol 1225 called SET (Secure Electronic Transaction) that provides for credit 1226 and debit card payments. We will analyze the authorization aspects 1227 from an architectural viewpoint. We will apply concepts and terms 1228 defined in [2]. 1230 We are not here proposing SET as a standard authorization protocol. 1231 Rather, we are examining the SET model as a way of understanding the 1232 e-commerce problem domain so that we can derive requirements that an 1233 authorization protocol would have to meet in order to be used in that 1234 domain. 1236 E-commerce protocols and mechanisms such as those described in [16] 1237 may not only be important to allow customers to shop safely in 1238 Cyberspace, but may also be important for purchases of Internet 1239 services as well. With emerging technologies allowing Internet 1240 transport services to be differentiated, an inherently more complex 1241 pricing model will be required as well as additional payment methods. 1242 Flexible authorization of services will be an important aspect to 1243 allow, for example, globally roaming users ad hoc allocation of 1244 premium bandwidth with an ISP who is authorized to accept certain 1245 credit card brands. 1247 6.1. Model Description 1249 The establishment of a model involves four steps: 1251 1. identification of the components that are involved and what 1252 they are called in this specific environment, 1253 2. identification of the relationships between the involved parties 1254 that are based on some form of agreement, 1255 3. identification of the relationships that are based on trust, and 1256 4. consideration of the sequence of messages exchanged between 1257 components. 1259 6.1.1. Identification of Components 1261 We will consider the components of an electronic commerce transaction 1262 in the context of the conceptual entities defined in [2]. 1264 - The Cardholder (User) -- the person or organization that is to 1265 receive and pay for the goods or services after a request to 1266 purchase has been received. In SET terms this is called a 1267 Cardholder. 1269 - The Issuer (User Home Organization) -- the financial organization 1270 that guarantees to pay for authorized transactions to purchase 1271 goods or services on behalf of the User when using a debit or 1272 credit card it issues. The financial organization (typically a 1273 bank or Brand Organization) will transfer money from the user 1274 account to the account the party to which the User instructs it to 1275 send the payment. The issued card authorizes the User to use the 1276 card for payments to merchants who are authorized to accept the 1277 card. In SET terms this organization is called the Issuer. This 1278 organization is considered "home" to the Cardholder. 1280 - The Merchant (Service Provider) -- the organization from whom the 1281 purchase is being made and who is legally responsible for 1282 providing the goods or services and receives the benefit of the 1283 payment made. In SET terms this organization is called a 1284 Merchant. The Cardholder is considered to be "foreign" to the 1285 Merchant. 1287 - The Acquirer (Broker) -- the organization that processes credit or 1288 debit card transactions. Although in reality this function may be 1289 rather complex and may span several organizations, we will simply 1290 assume this organization to be a Brand Organization fulfilling the 1291 role of the Acquirer as defined in SET. The Acquirer establishes 1292 an account with the Merchant. The Acquirer operates a Payment 1293 Gateway that will accept payment authorization requests from 1294 authorized merchants and provide responses from the issuer. The 1295 Acquirer will forward an authorization request to the Issuer. The 1296 Acquirer is considered "home" to the Merchant. 1298 As the SET document [16] notes, a Brand Organization (credit card 1299 organization) may handle both the Issuer function and Acquirer 1300 function that operates a Payment Gateway. For simplicity, we 1301 therefore assume that the authorization role of Broker (Acquirer) and 1302 User Home Organization (Issuer) both belong to the Brand 1303 Organization. 1305 In order to be more descriptive we now use the SET terms. In the 1306 requirements section these terms are mapped back into the 1307 authorization framework terms again. 1309 6.1.2. Identification of Contractual Relationships 1311 Contractual relationships are illustrated in figure 15, below. 1313 - The Cardholder has a contractual relationship with the card 1314 Issuer. The Cardholder holds an account with the Issuer and 1315 obtains an account number. 1317 - The Merchant has a contractual relationship with the Acquirer. 1318 The Merchant obtains a Merchant ID from the Acquirer. 1320 - In the real world there may be no direct contractual relationship 1321 between the Issuer and the Acquirer. The contractual 1322 relationships allowing an Acquirer to relay a payment 1323 authorization request to an Issuer may be very complex and 1324 distributed over multiple organizations. For simplicity, however, 1325 we assume there are contracts in place allowing an Acquirer to 1326 request payment authorization from an Issuer. These contracts are 1327 facilitated by the Brand Organization. Therefore, in our 1328 simplified example, the Acquirer and Issuer belong to the same 1329 Brand Organization. The Acquirer operates a Payment Gateway for 1330 which it needs a Bank Identification Number (BIN). 1332 +----------------+ +------------------------+ 1333 | Issuer | | Acquirer | 1334 | (User Home | | (Broker) | 1335 | Organization) | | +------------------+ | 1336 | |=======| | Payment | | 1337 | | | | Gateway | | 1338 | | | +------------------+ | 1339 | | | | 1340 +----------------+ +------------------------+ 1341 || || 1342 || || 1343 || || 1344 +----------------+ +--------------------+ 1345 | Cardholder | | Merchant | 1346 | (User) | | (Service Provider) |---+ 1347 | | | | | 1348 | | | | | 1349 | | +--------------------+ | 1350 | | | | 1351 | | | Fulfillment | 1352 | | | | 1353 +----------------+ +----------------------+ 1355 Fig. 15 -- SET Contractual Relationships 1357 6.1.3. Identification of Trust Relationships 1359 It is important to recognize that there are two kinds of trust 1360 relationships: static and dynamic trust relationships. Static trust 1361 relationships in SET are established by means of a registration 1362 process that will request a certificate to be issued to the party 1363 that needs to be trusted and authorized to be part of a SET 1364 transaction. Dynamic trust is created at the time of a payment 1365 transaction and its subsequent authorization request. Note that at 1366 the issue phase of a certificate, based on identification and 1367 registration, the user of the certificate gets an implicit static 1368 authorization and a means of authenticating and securing messages. 1369 For this purpose a Certificate Authority (CA) will issue certificates 1370 that are used to sign and/or encrypt messages exchanged according to 1371 the SET protocol. 1373 6.1.3.1. Static Trust Relationships 1375 In the discussion that follows, refer to figure 16, below. 1377 +-------+ 1378 | Root | 1379 | CA | 1380 +-------+ CA = Certificate Authority 1381 | {C} = Certificate 1382 | 1383 +-----------------+ 1384 | Brand | 1385 | CA | 1386 +-----------------+ 1387 | | | 1388 | | +-------+ 1389 | | |Payment| 1390 +----------------+ | | |Gateway| +----------------------+ 1391 | Issuer | | | | CA | | Acquirer | 1392 | (User Home | +----------+ | +-------+ | (Broker) | 1393 | Organization) | |Cardholder| | | | +----------------+ | 1394 | | | CA | | +------+--+-{C} Payment | | 1395 | | +----------+ | 3 | | Gateway | | 1396 | | | | | +----------------+ | 1397 | | | +---------+ | | 1398 +----------------+ | | Merchant| +----------------------+ 1399 | | CA | 1400 | +---------+ 1401 | | 1402 +----------------+ | | +--------------------+ 1403 | Cardholder | | | | Merchant | 1404 | (User) | | | | (Service Provider) |--+ 1405 | {C}-+-----+ | | | | 1406 | | 1 +-----------+-{C} | | 1407 | | 2 | | | 1408 | | | | | 1409 | | +--------------------+ | 1410 | | | | 1411 | | | Fulfillment | 1412 | | | | 1413 +----------------+ +---------------------+ 1415 Fig. 16 -- SET Trust Relationships within a Brand Domain 1417 - The Brand Organization operates a Brand CA and is therefore the 1418 holder of the common trust within the described domain. All 1419 involved parties (Cardholder, Issuer, Merchant and Acquirer) are 1420 members of the same trust domain. We will identify three separate 1421 CA's which issue a certificate on behalf of the Issuer, the 1422 Acquirer and the Brand Organization. The Brand CA, according to a 1423 tree like hierarchy, certifies all underlying CA's. The Brand CA 1424 obtains its trust from a single Root Certificate Authority. 1425 Before any party can obtain a Certificate from a CA, the party 1426 must have some form of contractual relationship. 1428 - After an account has been established with the Issuer, the 1429 Cardholder has to register with a Cardholder CA (CCA) through a 1430 series of registration steps (1) as defined in the SET protocol. 1431 If the CCA approves the registration, the Cardholder will obtain a 1432 Cardholder Certificate. The CCA may be operated by the Brand 1433 Organization on behalf of the Issuer. The Cardholder Certificate 1434 is an electronic representation of the payment card. This process 1435 creates a trust relationship between the Cardholder and the Brand. 1436 After the cardholder has received the Cardholder Certificate, the 1437 Cardholder is authorized to perform payments to an authorized 1438 Merchant. 1440 - After the Merchant has obtained a Merchant ID from the Acquirer, 1441 the Merchant has to register with the Merchant CA (MCA) through a 1442 series of registration steps (2) as defined in the SET protocol. 1443 If the MCA approves the registration, the Merchant will obtain a 1444 Merchant Certificate. This process creates a trust relationship 1445 between the Merchant and the Brand. The MCA may be operated by 1446 the Brand Organization on behalf of the Acquirer. After 1447 registration, the Merchant is authorized to accept payment 1448 requests from Cardholders and to send authorization requests to 1449 the Acquirer's Payment Gateway. 1451 - After the Acquirer has obtained a valid Bank Identification Number 1452 (BIN), the Acquirer must register with the Payment Gateway CA 1453 (PCA) in order to obtain a Payment Gateway Certificate (3). The 1454 Payment Gateway Certificate authorizes the Gateway to accept 1455 payment authorization requests originating from Merchants within 1456 its trust domain. 1458 - The Acquirer and Issuer have a trust relationship via the Brand 1459 Organization. The trust relationship is not ensured by procedures 1460 or a mechanism defined by SET, as this is a problem solved by 1461 agreements between financial organizations facilitating the 1462 payment service. Again, for simplicity, we assume that the 1463 relationship ensures that payment authorization requests received 1464 by the Acquirer's gateway will be forwarded in a secure and 1465 efficient way to the Issuer and its response is handled in the 1466 same way. 1468 6.1.3.2. Dynamic Trust Relationships 1470 Note that there is no prior established static trust relationship 1471 between the Cardholder and the Merchant, as a Cardholder does not 1472 have to register with a Merchant or vice versa. The trust 1473 relationship is dynamically created during the communication process 1474 and is based on the common relationship with the Brand. By means of 1475 digital signatures using public key cryptography, the Cardholder's 1476 software is able to verify that the Merchant is authorized to accept 1477 the Brand Organization's credit card. The merchant is able to verify 1478 that the Cardholder has been authorized to use the Brand 1479 Organization's credit card. 1481 6.1.4. Communication Model 1483 The purchase request from Cardholder to Merchant and subsequent 1484 payment authorization exchange between Merchant and Acquirer is 1485 illustrated in figure 17 and described below. 1487 +----------------+ +------------------------+ 1488 | Issuer | | Acquirer | 1489 | (User Home | | (Broker) | 1490 | Organization) | | +------------------+ | 1491 | |<------+--| Payment | | 1492 | | 5 | | Gateway | | 1493 | |-------+->| | | 1494 | | 6 | +------------------+ | 1495 | | | /|\ | | 1496 +----------------+ +---------+---+----------+ 1497 | | 1498 |4 |7 1499 | \|/ 1500 +----------------+ +--------------------+ 1501 | Cardholder | | Merchant | 1502 | (User) | | (Service Provider) |---+ 1503 | |------>| | | 1504 | | 1 | | | 1505 | |<------| | | 1506 | | 2 | | | 1507 | |------>| | | 1508 | | 3 | | | 1509 | |<------| | | 1510 | | 8 | | | 1511 | | | | | | 1512 | | +-----------------+--+ | 1513 | | | |9 | 1514 | |<--------| Fulfillment \|/ | 1515 | | 10 | | 1516 +----------------+ +----------------------+ 1518 Fig. 17 -- Communication Sequence 1520 1. The Cardholder shops and decides to purchase some goods at 1521 merchant.com. The Cardholder has selected a list of goods and the 1522 Merchant's software has subsequently prepared an order form for 1523 the Cardholder indicating the price, the terms and conditions, 1524 and the accepted payment methods. The SET transaction starts at 1525 the moment the Cardholder indicates that he or she wants to pay 1526 for the goods using a certain payment brand. The Cardholder 1527 software sends a request to the Merchant that initiates the 1528 payment process. 1530 2. The Merchant checks the order and signs it and returns it to the 1531 Cardholder including a certificate from the Acquirer's Gateway 1532 that allows the Cardholder to encrypt payment instructions that 1533 are only relevant to the Gateway and not to the Merchant (e.g., 1534 the Cardholder's credit card information). The Cardholder also 1535 includes his or her own certificate. 1537 3. The Cardholder now verifies both certificates (the software has 1538 the CA's root certificate). The Cardholder software generates a 1539 message containing the order information and the payment 1540 instructions that is signed by the Cardholder. Using the Gateway 1541 Certificate, it will encrypt the Payment Instruction so that it 1542 will only be readable by the Gateway. The Cardholder will 1543 include his or her certificate. 1545 4. The Merchant verifies the Cardholder certificate and checks the 1546 message integrity. He or she will now process the payment and 1547 issue a payment authorization request to the gateway. The 1548 payment authorization request contains the Cardholder's 1549 certificate and both Merchant certificates. 1551 5. The Gateway verifies the Merchant's signature certificate and 1552 that the Merchant signed the authorization request. Next it will 1553 obtain the account information and payment instructions and will 1554 check the message integrity and the Cardholder's certificate. If 1555 everything is in proper order it will send an authorization 1556 request to the Issuer via a secure bank network. 1558 6. The issuer returns the authorization. 1560 7. The Acquirer's Gateway generates an authorization response which 1561 includes the gateway's certificate. 1563 8. The Merchant checks the authorization response and completes the 1564 process by forwarding a purchase response to the Cardholder. 1566 9. The Merchant software authorizes the delivery of the purchased 1567 goods. 1569 10. The Cardholder receives the purchased goods. 1571 6.2. Multi Domain Model 1573 In the previous "single" domain case we already assume that there are 1574 multiple Cardholders, Merchants, Issuers and Acquirers. However all 1575 these parties belong to a single trust domain as there is only a 1576 single CCA, MCA and PCA. The trust relationship between multiple 1577 cardholders and multiple Issuers go via a single CCA in the same way 1578 as the trust relationship between an Acquirer and a Merchant uses the 1579 same MCA. The multi-domain case arises when there are multiple 1580 domains of CCA's, MCA's and PCA's. In SET these domains reside under 1581 a particular Geopolitical CA (GCA) which is illustrated in figure 18. 1583 +-----------+ 1584 | Root CA | 1585 | | 1586 +-----------+ 1587 | 1588 | 1589 +----------------------|-------------------------------+ 1590 +-----------------------------------------------------+ | 1591 | Brand CA | | 1592 | |-+ 1593 +-----------------------------------------------------+ 1594 | 1595 | 1596 +----------------------|-------------------------------+ 1597 +-----------------------------------------------------+ | 1598 | Geopolitical CA | | 1599 | |-+ 1600 +-----------------------------------------------------+ 1601 | | | 1602 | | | 1603 +----|--------+ +---|-------+ +-------|----------+ 1604 +------------+ | +----------+ | +-----------------+ | 1605 | Cardholder | | | Merchant | | | Payment Gateway | | 1606 | CA |-+ | CA |-+ | CA |-+ 1607 +------------+ +----------+ +-----------------+ 1609 Fig. 18 -- SET Certificate Management Architecture 1611 A GCA may represent a country or region. The architecture defines a 1612 trust hierarchy needed to manage and verify SET Certificates as these 1613 need to be issued, renewed or revoked. Each geopolitical region may 1614 have different policies for issuing, renewing or revoking 1615 certificates. However once certificates have been issued, Cardholders 1616 and Merchants belonging to different GCA's can still be recognized as 1617 belonging to the same Brand. This will allow a European Cardholder 1618 to purchase goods in the U.S. The U.S. Acquirer's gateway will 1619 recognize that the Cardholder belongs to the same Brand and will 1620 therefore accept a payment authorization request. 1622 6.3. Requirements 1624 Many e-commerce environments do not use SET. Other mechanisms exist 1625 based on SSL, XML, and S/MIME. Also a mechanism that uses SET only 1626 for the payment authorization to the Gateway exists and is known as 1627 half SET. However, using the model described in this document, we 1628 can derive a fairly comprehensive set of protocol requirements for 1629 e-commerce. In these requirements, the SET terms are replaced again 1630 by the descriptive model terms: 1632 Cardholder = User 1633 Merchant = Service Provider 1634 Issuer = User Organization 1635 Acquirer = Broker 1637 1. The Authorization mechanism must allow trust relationships to be 1638 established before any requests can be made from the User to the 1639 Service Provider and from the Service Provider via a Broker to the 1640 User Organization. This process will enable the parties to 1641 communicate securely by creating an authenticated channel and, by 1642 so doing, implicitly authorizing its usage. 1644 2. Upon receipt of any request or response, entities need to be able 1645 to verify whether the transmitting party is still authorized to 1646 send this request or response. 1648 3. The User must be able to authorize the Service Provider to request 1649 an authorization from the User Home Organization. 1651 4. The User must be able to authorize fulfillment of a proposed 1652 service offer from the Service Provider. 1654 Other requirements related to the authorization process: 1656 Integrity 1658 5. For any authorization request or response, the receiving party 1659 needs to verify that the content of the message has not been 1660 altered. 1662 Confidentiality/Privacy 1664 6. The User must be able to pass information relevant to the session 1665 authorization process to the User Home Organization via a Broker 1666 and the Service Provider without allowing the Broker or the 1667 Service Provider to examine its content. 1669 7. The User Home Organization must be able to communicate information 1670 relevant to the session authorization via the Broker and the 1671 Service Provider to the User without allowing the Broker or the 1672 Service Provider to examine its content. 1674 Nonrepudiation 1676 8. There is a need for a recorded, authenticated and authorized 1677 agreement about the request for and delivery of service. 1679 7. Computer Based Education and Distance Learning 1681 This section describes the authorization aspects of computer based 1682 distance learning environments. In this section we will model the 1683 relationships and working practices in a hypothetical university 1684 environment where a student enrolls in courses, attends lectures, and 1685 takes the corresponding exams from remote locations (distance 1686 learning) or via computer equipment (computer based education). When 1687 completed successfully, a student is authorized to enroll in a set of 1688 subsequent courses according to his or her curriculum requirements. 1689 Completion of required courses with passing grades results in 1690 graduation. 1692 Although this section specifically describes an example of a student 1693 taking courses at a faculty (department) of the university, the 1694 resulting requirements should also be valid for other applications in 1695 similar environments, e.g. library loans, electronic abstract and 1696 reprint services, computer and network access, use of copy machines, 1697 budget management, store retrievals, use of coffee machines and 1698 building access. 1700 It is important to recognize that the AAA environment we are 1701 describing also needs to be managed. For example, for an application 1702 such as budget management, it is necessary to delegate budget 1703 authority from a central financial department to budget managers in 1704 education or faculty groups. An AAA environment must allow creation 1705 of policy rules either by certain individuals or by other AAA servers 1706 with with authorization to do so. 1708 7.1. Model Description 1710 The establishment of the model involves four steps: 1712 1. identification of the components that are involved and what they 1713 are called in this specific environment, 1715 2. identification of the contractual relationships between the 1716 involved parties, 1718 3. identification of the relationships that are based on trust, and 1720 4. consideration of the sequence of messages exchanged between 1721 components. 1723 7.1.1. Identification of Components 1725 We will consider the components of a distance learning environment in 1726 the context of the conceptual entities defined in [2]. 1728 - The Student (User) -- the person enrolling in a course (Service) 1729 and taking the corresponding exam. 1731 - The Educator (Service Equipment) -- the education content server 1732 for which the content is delivered by the Professor. 1734 - The Educator Authorization Module (Service Provider AAA Server). 1735 This module must check at the service access point whether the 1736 student complies with the requirements for enrolling in the 1737 course. The authorization may be based on both local (by the 1738 professor) and remote policies (originating from the faculty). 1739 Rules must allow enough flexibility to prevent students from being 1740 falsely denied access to courses. Strict rules must only be 1741 applied at graduation time. 1743 - The Faculty (Service Provider) -- the organization (department in 1744 U.S. terms) which controls the Service "Equipment" of which the 1745 Educator is one example. 1747 - The Curriculum Commission (Part of User Home Organization) -- body 1748 responsible for creating rules by which a student is allowed to 1749 enroll in a certain course and how this course will count toward 1750 his or her graduation requirements. Students may legally take any 1751 course available at any time, however the Curriculum Commission 1752 will decide whether this course will contribute towards their 1753 graduation. When a Student registers with a certain Educator, the 1754 Educator may check with the Curriculum Commission AAA server 1755 whether the course will count towards graduation and confirm this 1756 with the student. 1758 - The Student Administration (Part of User Home Organization) -- the 1759 administrative organization that authorizes students to enroll in 1760 courses if certain criteria, including financial criteria, are 1761 met. Next to the student, the Student Administration will keep 1762 track of any exam results for the student and will issue a 1763 graduation certificate when all criteria are met. 1765 7.1.2. Identification of Contractual Relationships 1767 Contractual relationships are illustrated in figure 19, below. Based 1768 on contract relationships,specific trust relationships are created as 1769 required. 1771 Although not shown in figure 19, it is assumed that the university 1772 has contractual relationships with the faculties in which every 1773 faculty is allowed and obligated to build, maintain and present one 1774 or more specific studies. 1776 +---------------------------------------------+ 1777 | +-----------------------------------------+ | 1778 | | Faculty administration | | 1779 | |+----------------+ +----------------+| | 1780 | |O Student | | Curriculum || | 1781 | *| Administration O*****O Commission || | 1782 |*|| AAA Server | | AAA Server || | 1783 */|+---O------O-----+ +-----O------O---+| | 1784 *//| * * * * | | 1785 *// +----*---------*-----------*---------*----+ | 1786 *//| * || * * || * | 1787 *// | * || * * || * | 1788 *// | * || * || * | 1789 *// | * || * * || * | 1790 *// | * || * * || * | 1791 *// | +----*---------*--+ +--*---------*----+ | 1792 *// | | * * | | * * | 1793 *// | |+---O------O----+| |+----O------O---+| | 1794 *// | || Educator A || || Educator B || | 1795 *// | || AAA Server || || AAA Server || | 1796 *// | || Service admin.|| || Service admin.|| | 1797 *// | |+---O-----------+| |+-----------O---+| | 1798 *// | | * | | * | | 1799 +-O-------+ | | * | | * | | 1800 | | | |+---O-----------+| |+-----------O---+| | 1801 | Student | | || Educator || || Educator || | 1802 | | | || Course A || || Course B || | 1803 | | | |+---------------+| |+---------------+| | 1804 +---------+ | +-----------------+ +-----------------+ | 1805 | Faculty | 1806 +---------------------------------------------+ 1808 // = contractual relationship 1809 ** = trust relationship 1811 Fig. 19 -- Contractual relationships - single domain case 1813 As shown in figure 19, the Student has a contractual relationship 1814 with the Faculty. The contract allows the Student to pursue a course 1815 of study consisting of a set of courses. Courses are presented to 1816 the Students by the Educators. A course of study may consist of 1817 courses from different Faculties. 1819 Faculties have contracts among them allowing Students from one 1820 Faculty to enroll in courses from other Faculties. 1822 Faculties instantiate Educators based on a contract between the 1823 Faculty Administration and the professor implementing and managing 1824 the Educator. Authorization is based on policy rules defined by one 1825 or more parties in the contractual relationships. For example, a 1826 professor has a policy to give the course only in the afternoon and 1827 the Faculty has a policy to give the course to their own students and 1828 students from faculty-x but not, when oversubscribed, to faculty-y 1829 students. 1831 7.1.3. Identification of Trust Relationships 1833 Figure 19 illustrates relevant trust relationships which statically 1834 enable AAA entities to communicate certain attributes in our 1835 simplified example. However, in order for the illustrated entities to 1836 work, other trust relationships that are not illustrated must already 1837 be in existence: 1839 - A trust relationship based on a contract between the Faculty and 1840 the university enables a faculty to create and teach specific 1841 courses belonging to a course of study. 1843 - Although not further detailed in this example, it is worth noting 1844 that trust relationships between faculties authorize students from 1845 one faculty to enroll in courses with other faculties. 1847 - A professor responsible for the content of the Educator has a 1848 trust relationship with the administration of the faculty. 1849 Through this relationship, the faculty enables the professor to 1850 teach one or more courses fitting the requirements of the 1851 Curriculum Commission. 1853 Figure 19 illustrates the following trust relationships: 1855 - When a person wants to become a Student of a Faculty, the contract 1856 requires the Student to register with the Student Administration 1857 of the Faculty. If the requirements for registration are met, a 1858 trust relationship with the Faculty enables the Student to 1859 register for courses. For this purpose, the Student 1860 Administration will issue a student card which contains a student 1861 ID and information about the Faculty he or she is admitted to. 1862 The Student Administration will only admit Students who pay the 1863 necessary fees and have met certain prerequisites. The Student 1864 Administration will also keep track of Student grades and will 1865 ultimately issue a certificate at graduation. The Student 1866 Administration AAA server has access to relevant student data and 1867 will only issue grade information and other student-related 1868 information to authorized parties which have a specified means of 1869 authenticating. 1871 - The Curriculum Commission AAA server needs a trust relationship 1872 with the Student Administration AAA server in order to obtain 1873 grade information to check whether a student has met the required 1874 course prerequisites. The Curriculum Commission creates certain 1875 rules within its AAA server which are evaluated when a particular 1876 student attempts to register for a particular course in order to 1877 give an advisory to the student. 1879 - The Educator AAA server needs a trust relationship with the 1880 Student Administrator AAA server in order to verify wether this 1881 particular Student is in good standing with the Faculty. Only 1882 authorized Educator AAA servers may send requests to the Student 1883 Administration AAA server. 1885 - The Educator AAA server needs a trust relationship with the 1886 Curriculum Commission AAA server in order to allow the Educator to 1887 obtain an advisory for the Student whether this course is 1888 consistent with his or her curriculum or whether the student meets 1889 the course prerequisites. Only authorized Educator AAA servers 1890 may send requests to the Curriculum AAA Server. 1892 7.1.4. Sequence of Requests 1894 For the sake of simplicity, we take the example of a student from the 1895 same faculty as the professor. 1897 In this example the following interactions take place for a 1898 hypothetical course (see figure 20). 1900 +----------------------------------------------+ 1901 | | 1902 | +----------------+ 6 +----------------+ | 1903 | | Student |----->| Curriculum | | 1904 | | Administration |<-----| Commission | | 1905 | | AAA Server | 5 | AAA Server | | 1906 | +----------------+ _ +----------------+ | 1907 | /|\ | /|/ | 1908 | | | / / | 1909 | 2,8| |3 / /6 | 1910 | | | 4/ / | 1911 | | | / / | 1912 | | | / / | 1913 | | \|/ /|/ | 1914 | +---------------+ -- +---------------+ | 1915 | | Educator A | | Educator B | | 1916 | | AAA Server | | AAA Server | | 1917 | +---------------+ +---------------+ | 1918 | /|\ | | 1919 |2,4,8| |3,6 | 1920 +---------+ | | \|/ | 1921 | | 1,7 | +---------------+ +---------------+ | 1922 | Student |------->| Educator | | Educator | | 1923 | |<-------| Course A | | Course B | | 1924 | | 7,8 | +---------------+ +---------------+ | 1925 +---------+ | Faculty | 1926 +----------------------------------------------+ 1928 Fig. 20 -- AAA transactions - single domain case 1930 1. After the Professor has set up the Service Equipment (Educator) 1931 students come to it presenting their ID (college card, 1932 name+faculty) and ask to be admitted to the course. 1934 2. The Educator checks the ID to determine it is indeed dealing with 1935 a student from the faculty. This can include a check with the 1936 Student Administration. 1938 3. The Student Administration replies to the Educator AAA Server, and 1939 the Educator AAA Server replies to the Educator. 1941 4. The Educator checks the request of the Student against its own 1942 policy (courses only in the afternoon) and checks with the 1943 Curriculum Commission whether this student is advised to take the 1944 course. The necessary information is not normally known to or 1945 maintained by the professor. 1947 5. The Curriculum Commission may check against the Student 1948 Administration to see if the Student had the necessary grades for 1949 the previous courses according to the policies set by the 1950 Curriculum Commission. 1952 6. The Student Administration replies to the Curriculum Commission, 1953 the Curriculum Commission replies to the Educator AAA Server, and 1954 the Educator AAA Server replies to the Educator. 1956 7. If now authorized, the Student is presented the material and the 1957 Student returns completed exams. 1959 8. If the Student passes the tests, the Educator informs both the 1960 Student and the Student Administration that the Student has 1961 passed. 1963 7.2. Requirements 1965 We identify the following requirements for an AAA server environment 1966 for this example: 1968 1. It must be possible to delegate authority to contracted partners. 1969 Although this requirement is not explicit in the limited example, 1970 the relationship between University and Faculty may require 1971 delegation of authority regarding the curriculum to the Faculty. 1972 In the case of budget management, this requirement is evident. 1974 2. A system to manage the delegated authority must be established. 1975 It is possible that this is just another AAA server environment. 1976 This comes from the fact that one partner requires the presence of 1977 specific rules to be in the AAA server of another partner. For 1978 example, the Faculty must be sure that certain checks are 1979 performed by the Educator's AAA server. 1981 3. AAA requests must either be evaluated at the AAA server queried or 1982 else parts of the request must be forwarded to another AAA server 1983 which can decide further on the request. As such, it must be 1984 possible to build a network of AAA servers in which each makes the 1985 decisions it is authorized to make by the relationships among the 1986 entities, e.g., a request from the Educator to the Curriculum 1987 Commission may result in a request to the Student Administration. 1989 4. Transaction logs must be maintained to support non-repudiation for 1990 the grades of the students. This recording should be time-stamped 1991 and allow signing by authorized entities. A student should sign 1992 for taking an exam and this should be kept by the Educator's AAA 1993 server. After grading, the professor should be able to sign a 1994 grade and send it to the Student Administrator and the Student 1995 Administrator's AAA server should log and timestamp this event. 1997 5. Three types of AAA messages are required: 1999 - authorization requests and responses for obtaining 2000 authorization, 2001 - notification messages for accounting purposes, and 2002 - information requests and responses for getting information 2003 regarding the correct construction of requests and for querying 2004 the database of notifications. 2006 8. Security Considerations 2008 The authorization applications discussed in this document are modeled 2009 on the framework presented in [2]. Security considerations relative 2010 to the authorization framework are discussed in [2]. 2012 Specific security aspects of each authorization application presented 2013 in this document are discussed in the relevant section, above. 2015 Security aspects of the applications, themselves, are discussed in 2016 the references cited below. 2018 Glossary 2020 Attribute Certificate -- structure containing authorization 2021 attributes which is digitally signed using public key 2022 cryptography. 2024 Contract Relationship -- a relation established between two or more 2025 business entities where terms and conditions determine the 2026 exchange of goods or services. 2028 Distributed Service -- a service that is provided by more than one 2029 Service Provider acting in concert. 2031 Dynamic Trust Relationship -- a secure relationship which is 2032 dynamically created between two entities who may never have had 2033 any prior relationship. This relationship can be created if the 2034 involved entities have a mutually trusted third party. Example: A 2035 merchant trusts a cardholder at the time of a payment transaction 2036 because they both are known by a credit card organization. 2038 Policy Decision Point (PDP) -- The point where policy decisions are 2039 made. 2041 Policy Enforcement Point (PEP) -- The point where the policy 2042 decisions are actually enforced. 2044 Resource Manager -- the component of an AAA Server which tracks the 2045 state of sessions associated with the AAA Server or its associated 2046 Service Equipment and provides an anchor point from which a 2047 session can be controlled, monitored, and coordinated. 2049 Roaming -- An authorization transaction in which the Service Provider 2050 and the User Home Organization are two different organizations. 2051 (Note that the dialin application is one for which roaming has 2052 been actively considered, but this definition encompasses other 2053 applications as well.) 2055 Security Association -- a collection of security contexts, between a 2056 pair of nodes, which may be applied to protocol messages exchanged 2057 between them. Each context indicates an authentication algorithm 2058 and mode, a secret (a shared key, or appropriate public/private 2059 key pair), and a style of replay protection in use. [14] 2061 Service Equipment -- the equipment which provides a service. 2063 Service Provider -- an organization which provides a service. 2065 Static Trust Relationship -- a pre-established secure relationship 2066 between two entities created by a trusted party. This 2067 relationship facilitates the exchange of AAA messages with a 2068 certain level of security and traceability. Example: A network 2069 operator (trusted party) who has access to the wiring closet 2070 creates a connection between a user's wall outlet and a particular 2071 network port. The user is thereafter trusted -- to a certain 2072 level -- to be connected to this particular network port. 2074 User -- the entity seeking authorization to use a resource or a 2075 service. 2077 User Home Organization (UHO) -- An organization with whom the User 2078 has a contractual relationship which can authenticate the User and 2079 may be able to authorize access to resources or services. 2081 References 2083 [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", 2084 RFC 2026, BCP 9, October 1996. 2086 [2] Vollbrecht, John, et al, "AAA Authorization Framework", draft- 2087 ietf-aaa-authz-arch-00.txt, October 1999. 2089 [3] Vollbrecht, John, et al, "AAA Authorization Requirements", 2090 draft-ietf-aaa-authorization-reqs-01.txt, October 1999. 2092 [4] Bradner, Scott, "Key words for use in RFCs to Indicate 2093 Requirement Levels", RFC 2119, BCP 14, March 1997. 2095 [5] Aboba, Bernard and Glen Zorn, "Criteria for Evaluating Roaming 2096 Protocols", RFC 2477, January 1999. 2098 [6] Beadles, Mark Anthony, "Criteria for Evaluating Network Access 2099 Server Protocols", draft-ietf-nasreq-criteria-02.txt, October 2100 1999. 2102 [7] Aboba, Bernard and Mark Beadles, "The Network Access 2103 Identifier", RFC 2486, January 1999. 2105 [8] Rigney, Carl, Allan C. Rubens, William Allen Simpson, and Steve 2106 Willens, "Remote Authentication Dial In User Service (RADIUS)", 2107 RFC 2138, April 1997. 2109 [9] Calhoun, Pat R. and Glen Zorn, "Roamops 2110 Authentication/Authorization Requirements" draft-ietf-aaa- 2111 roamops-auth-req-00.txt, March 1999. 2113 [10] Perkins, Charles, Editor: "IP Mobility Support", RFC 2002, 2114 October 1996. 2116 [11] Dommety, Gopal, et al, "Mobile IP Authentication, Authorization, 2117 and Accounting Requirements", draft-ietf-aaa-mobile-ip-req- 2118 01.txt, October 1999. 2120 [12] Hiller, Tom, et al, "cdma2000 Wireless Data Requirements for 2121 AAA", draft-hiller-cdma2000-AAA-00.txt, November 1999. 2123 [13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares, 2124 "A Discussion of Bandwidth Broker Requirements for Internet2 2125 Qbone Deployment", ver. 0.7, August 1999, 2126 http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf. 2128 [14] deBry, Roger, "Internet Printing Protocol/1.0: Model and 2129 Semantics", RFC 2566, April 1999. 2131 [15] Burdett, David, "Internet Open Trading Protocol - IOTP", draft- 2132 ietf-trade-iotp-v1.0-protocol-03.txt, February 1999. 2134 [16] "SET Secure Electronic Transaction Specification Book 1: 2135 Business Description", Version 1.0, May 31, 1997, 2136 http://www.setco.org/download/set_bk1.pdf. 2138 Authors' Addresses 2140 John R. Vollbrecht 2141 Merit Network, Inc. 2142 4251 Plymouth Rd., Suite 2000 2143 Ann Arbor, MI 48105 2144 USA 2146 Phone: +1 734 763 1206 2147 Fax: +1 734 647 3745 2148 EMail: jrv@merit.edu 2150 Pat R. Calhoun 2151 Network and Security Research Center, Sun Labs 2152 Sun Microsystems, Inc. 2153 15 Network Circle 2154 Menlo Park, California, 94025 2155 USA 2157 Phone: +1 650 786 7733 2158 Fax: +1 650 786 6445 2159 EMail: pcalhoun@eng.sun.com 2161 Stephen Farrell 2162 Baltimore Technologies 2163 61 Fitzwilliam Lane 2164 Dublin 2 2165 Ireland 2167 Phone: +353 1 647 7406 2168 Fax: +353 1 647 7499 2169 EMail: stephen.farrell@baltimore.ie 2171 Leon Gommans 2172 Cabletron Systems EMEA 2173 Kerkplein 24 2174 2841 XM Moordrecht 2175 The Netherlands 2177 Phone: +31 182 379278 2178 Email: gommans@cabletron.com 2180 George M. Gross 2181 Lucent Technologies 2182 184 Liberty Corner Road, m.s. LC2N-D13 2183 Warren, NJ 07059 2184 USA 2186 Phone: +1 908 580 4589 2187 Fax: +1 908 580 7430 2188 Email: gmgross@lucent.com 2190 Betty de Bruijn 2191 Interpay Nederland B.V. 2192 Eendrachtlaan 315 2193 3526 LB Utrecht 2194 The Netherlands 2196 Phone: +31 30 2835104 2197 Email: betty@euronet.nl 2199 Cees T.A.M. de Laat 2200 Physics and Astronomy dept. 2201 Utrecht University 2202 Pincetonplein 5, 2203 3584CC Utrecht 2204 Netherlands 2206 Phone: +31 30 2534585 2207 Phone: +31 30 2537555 2208 EMail: delaat@phys.uu.nl 2210 Matt Holdrege 2211 Lucent Technologies 2212 1701 Harbor Bay Pkwy. 2213 Alameda, CA 94502 2214 USA 2216 Phone: +1 510 747 2711 2217 Email: holdrege@lucent.com 2219 David W. Spence 2220 Merit Network, Inc. 2221 4251 Plymouth Rd., Suite 2000 2222 Ann Arbor, MI 48105 2223 USA 2225 Phone: +1 734 615 2630 2226 Fax: +1 734 647 3745 2227 EMail: dwspence@merit.edu