idnits 2.17.1 draft-irtf-aaaarch-generic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 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 25 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2000) is 8808 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational draft: draft-irtf-aaaarch-authorization-framework (ref. '2') ** Downref: Normative reference to an Informational draft: draft-irtf-aaaarch-authorization-apps (ref. '3') ** Downref: Normative reference to an Informational draft: draft-irtf-aaaarch-authorization-reqs (ref. '4') ** Downref: Normative reference to an Informational RFC: RFC 2704 (ref. '5') Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT C. de Laat 2 draft-irtf-aaaarch-generic-01.txt Utrecht University 3 G. Gross 4 Lucent Technologies 5 L. Gommans 6 Cabletron Systems EMEA 7 J. Vollbrecht 8 Merit Network, Inc. 9 D. Spence 10 Merit Network, Inc. 11 March 2000 13 Generic AAA Architecture 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026 [1]. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This memo describes work in progress within the AAAarch Research 37 Group. Comments are welcome and should be submitted to 38 aaaarch@fokus.gmd.de. 40 Distribution of this memo is unlimited. 42 Copyright Notice 44 Copyright (C) The Internet Society 2000. All Rights Reserved. 46 Abstract 48 This memo proposes an AAA architecture that would incorporate a 49 generic AAA server along with an application interface to a set of 50 Application Specific Modules that could perform application specific 51 AAA functions. A separation of AAA functions required in a multi- 52 domain environment is then proposed using a layered protocol 53 abstraction. The long term goal is to create a generic framework 54 which allows complex authorizations to be realized through a network 55 of interconnected AAA servers. 57 Table of Contents 59 Status of this Memo ............................................ 1 60 Copyright Notice ............................................... 1 61 Abstract ....................................................... 2 62 1. Introduction ................................................ 3 63 2. Generic AAA Architecture .................................... 4 64 2.1. Architectural Components of a Generic AAA Server ....... 4 65 2.1.1. Authorization Rule Evaluation ................... 5 66 2.1.2. Application Specific Module (ASM) ............... 5 67 2.1.3. Authorization Event Log ......................... 6 68 2.1.4. Policy Repository ............................... 6 69 2.1.5. Request Forwarding .............................. 6 70 2.2. Generic AAA Server Model ............................... 6 71 2.2.1. Generic AAA Server Interactions ................. 7 72 2.2.2. Compatibility with Legacy Protocols ............. 8 73 2.2.3. Interaction between the ASM and the Service ..... 8 74 2.2.4. Multi-domain Architecture ....................... 9 75 2.3. Model Observations ..................................... 10 76 2.4. Suggestions for Future Work ............................ 11 77 3. Layered AAA Protocol Model .................................. 12 78 3.1. Elements of a Layered Architecture ..................... 13 79 3.1.1. Service Layer Abstract Interface Primitives ..... 14 80 3.1.2. Service Layer Peer End Point Name Space ......... 14 81 3.1.3. Peer Registration, Discovery, and Location 82 Resolution ............................................. 14 83 3.1.4. Trust Relationships Between Peer End Points ..... 14 84 3.1.5. Service Layer Finite State Machine .............. 14 85 3.1.6. Protocol Data Unit Types ........................ 15 86 3.2. AAA Application Specific Service Layer ................. 15 87 3.3. Presentation Service Layer ............................. 16 88 3.4. AAA Transaction/Session Management Service Layer ....... 17 89 3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20 90 3.6. AAA-TSM Layer End Point Name Space ..................... 21 91 3.7. Protocol Stack Examples ................................ 21 92 4. Security Considerations ..................................... 22 93 Glossary ....................................................... 23 94 References ..................................................... 23 95 Authors' Addresses ............................................. 23 97 1. Introduction 99 The work for this memo was done by a group that originally was the 100 Authorization subgroup of the AAA Working Group of the IETF. When 101 the charter of the AAA working group was changed to focus on MobileIP 102 and NAS requirements, the AAAarch Research Group was chartered within 103 the IRTF to continue and expand the architectural work started by the 104 Authorization subgroup. This memo is one of four which were created 105 by the subgroup. This memo is a starting point for further work 106 within the AAAarch Research Group. It is still a work in progress 107 and is published so that the work will be available for the AAAarch 108 subgroup and others working in this area, not as a definitive 109 description of architecture or requirements. 111 The authorization subgroup of the AAA Working Group proposed an "AAA 112 Authorization Framework" [2] illustrated with numerous application 113 examples [3] which in turn motivates a proposed list of authorization 114 requirements [4]. This memo builds on the framework presented in [2] 115 by proposing an AAA infrastructure consisting of a network of 116 cooperating generic AAA servers communicating via a standard 117 protocol. The protocol should be quite general and should support 118 the needs of a wide variety of applications requiring AAA 119 functionality. To realize this goal, the protocol will need to 120 operate in a multi-domain environment with multiple service providers 121 as well as entities taking on other AAA roles such as User Home 122 Organizations and brokers. It should be possible to combine requests 123 for multiple authorizations of different types in the same 124 authorization transaction. The AAA infrastructure will be required 125 to forward the components of such requests to the appropriate AAA 126 servers for authorization and to collect the authorization decisions 127 from the various AAA servers consulted. All of this activity is 128 perfectly general in nature and can be realized in the common 129 infrastructure. 131 But the applications requiring AAA services will each have their own 132 unique needs. After a service is authorized, it must be configured 133 and initialized. This will require application specific knowledge 134 and may require application specific protocols to communicate with 135 application specific service components. To handle these application 136 specific functions, we propose an application interface between a 137 generic AAA server and a set of one or more Application Specific 138 Modules (ASMs) which can carry out the unique functionality required 139 by each application. 141 Since the data required by each application for authentication, 142 authorization, or accounting may have unique structure, the standard 143 AAA protocol should allow the encapsulation of opaque units of 144 Application Specific Information (ASI). These units would begin with 145 a standard header to allow them to be forwarded by the generic 146 infrastructure. When delivered to the final destination, an ASI unit 147 would be passed by a generic AAA server across its program interface 148 to an appropriate ASM for application specific processing. 149 Nevertheless, it remains a goal of the design for information units 150 to be encoded in standard ways as much as possible so as to enable 151 processing by a generic rule based engine. 153 The interactions of the generic AAA server with the Application 154 Specific Modules and with each other to realize complex AAA functions 155 is explored in section 2. Then, in section 3, we attempt to further 156 organize the AAA functions into logical groups using a protocol 157 layering abstraction. This abstraction is not intended to be a 158 reference model ready to be used for protocol design. At this point 159 in the work, there are numerous questions that need to be addressed 160 and numerous problems that remain to be solved. It may be that an 161 abstraction other than layering will prove to be more useful or, more 162 likely, that the application layer will require some substructure of 163 its own. 165 Finally, in section 4, we show how the security requirements 166 identified in [4] can be met in the generic server and the 167 Application Specific Modules by applying security techniques such as 168 public key encryption or digital signatures to the Application 169 Specific Information units individually, so that different 170 stakeholders in the AAA server network can protect selected 171 information units from being deciphered or altered by other 172 stakeholders in an authentication, authorization, or accounting 173 chain. 175 2. Generic AAA Architecture 177 For the long term we envision a generic AAA server which is capable 178 of authenticating users, handling authorization requests, and 179 collecting accounting data. For a service provider, such a generic 180 AAA server would be interfaced to an application specific module 181 which manages the resource for which authorization is required. 182 Generic AAA components would also be deployed in other administrative 183 domains performing authorization functions. 185 2.1. Architectural Components of a Generic AAA Server 186 2.1.1. Authorization Rule Evaluation 188 The first step in the authorization process is for the user or an 189 entity operating on the user's behalf to submit a well-formatted 190 request to an AAA server. A generic AAA server has rules (logic 191 and/or algebraic formulas) to inspect the request and come to an 192 authorization decision. The first problem which arises is that 193 Application Specific Information (ASI) has to be separated from the 194 underlying logic for the authorization. Ideally the AAA server would 195 have a rule based engine at this point which would know the logic 196 rules and understand some generic information in the request, but it 197 would not know anything about application specific information except 198 where this information can be evaluated to give a boolean or 199 numerical value. It should be possible to create rules that refer to 200 data elements that were not considered when the application was 201 created. For example, one could request to do a remote virtual 202 control room experiment from home using a dialin provider. The 203 request would only be successful if the dialin access server allows 204 it and if there is bandwidth available (bandwidth broker) and if the 205 experimenter has the money to pay for it (E-Commerce). Possibly the 206 people who specified the bandwidth broker protocol did not think of 207 combining quality of service with a network service authorization in 208 a single AAA request, but this generic model would allow it. 210 +------+ +-------+ +-------+ +-------+ +-------+ 211 | | auth | | auth | | auth | | auth | | 212 | |<---->| AAA |<---->| AAA |<---->| AAA |<---->| AAA | 213 | | | | | | | | | | 214 | | +-------+ +-------+ +-------+ +-------+ 215 | User | | | | | 216 | | | +-------+ +-------+ +-------+ 217 | | | | BB | | BB | |Budget | 218 | | | +-------+ +-------+ +-------+ 219 | | | | | 220 | | +-------+ | | 221 | | |dial in| +-------+ +-------+ 222 | |<====>|service|<====>|network|<====>|network|<===> Experiment 223 +------+ +-------+ +-------+ +-------+ 225 user <-> dialin <-> backbone with BB <-> 227 Fig. 1 -- Example of a Multi Domain Multi Type of Server Request 229 2.1.2. Application Specific Module (ASM) 231 Ultimately an AAA server needs to interact with an application 232 specific module (ASM). In a service provider, the ASM would manage 233 resources and configure the service equipment to provide the 234 authorized service. It might also involve itself in the 235 authorization decision because it has the application specific 236 knowledge required. A user home organization (UHO) may require ASMs 237 as well, to perform application specific user authorization 238 functions. For example, a UHO ASM might be required to access 239 certain application specific databases or interpret application 240 specific service level specifications. 242 Whatever the role of an administration relative to an authorization 243 decision, the capabilities of the generic AAA server and the 244 interface between it and the ASMs remains the same. This interface 245 may be an Application Program Interface (API) or could even be a 246 protocol based interface. In this model, however, the application 247 specific module is regarded as as separate architectural component 248 from the generic AAA server. As such, it must be addressable and 249 must therefore be part of a global naming space. 251 2.1.3. Authorization Event Log 253 For auditing purposes, the generic server must have some form of 254 database to store time-stamped events which occur in the AAA server. 255 This database can be used to account for authorizations which were 256 given, but it can also be used in rules. One can imagine rules in 257 which an authorization is only given if some other event was logged 258 in the past. With the aid of certificates, this database could 259 support non-repudiation. 261 2.1.4. Policy Repository 263 A database containing the available services and resources about 264 which authorization decisions can be made and the policy rules to 265 make them is also needed. Here too, the naming space for the 266 services and resources is important since they must be addressable 267 from other AAA servers to be able to build complex authorization 268 requests. 270 2.1.5. Request Forwarding 272 Due to the multiple administrative domain (multi-kingdom) nature of 273 the AAA problem, a mechanism to forward messages between AAA servers 274 is needed. The protocol by which two AAA servers communicate should 275 be a peer-to-peer protocol. 277 2.2. Generic AAA Server Model 279 With the implementation of the above mentioned components, the AAA 280 server would be able to handle AAA requests. It would inspect the 281 contents of the request, determine what authorization is requested, 282 retrieve the policy rules from the repository, perform various local 283 functions, and then choose one of the following options to further 284 process each of the components of the request: 286 a) Let the component be evaluated by an attached ASM. 288 b) Query the authorization event log or the policy repository for the 289 answer. 291 c) Forward the component(s) to another AAA server for evaluation. 293 In the following sections we present the generic model. 295 2.2.1. Generic AAA Server Interactions 297 Figure 2 illustrates a generic AAA Server with connections to the 298 various architectural components described above. In this model, the 299 user or another AAA server contacts the AAA server to get 300 authorization, and the AAA server interacts with the service. The 301 request is sent to the AAA server using the future AAA protocol. The 302 server interacts with the service via a second protocol which we have 303 labeled as type "2" in the figure. We say no more of the type 2 304 protocol than that it must support some global naming space for the 305 application specific items. The same holds for the type 3 306 communication used to access the repository. 308 +------------------+ 309 | | 310 request <-----1----->|Generic AAA Server|<---1---> AAA server 311 |Rule based engine | 312 | |\ 313 +------------------+ 3 +------------+ 314 ^ \| Policy and | 315 | | event | 316 2 | repository | 317 | +------------+ 318 v 319 +------------------+ 320 | Application | 321 | Specific | 322 | Module | 323 +------------------+ 325 The numbers in the links denote types of communication. 327 Fig. 2 -- Generic AAA Server Interactions 329 2.2.2. Compatibility with Legacy Protocols 331 Because of the widespread deployment of equipment that implements 332 legacy AAA protocols and the desire to realize the functionality of 333 the new AAA protocol while protecting the investment in existing 334 infrastructure, it may be useful to implement a AAA gateway function 335 that can encapsulate legacy protocol data units within the messages 336 of the new protocol. Use of this technique, for example, would allow 337 Radius attribute value pairs to be encapsulated in Application 338 Specific Information (ASI) units of the new protocol in such a way 339 that the ASI units can be digitally signed and encrypted for end-to- 340 end protection between a service provider's AAA server and a home AAA 341 server communicating via a marginally trusted proxy AAA server. The 342 service provider's NAS would communicate via Radius to the service 343 provider's AAA server, but the AAA servers would communicate among 344 themselves via the new AAA protocol. In this case, the AAA gateway 345 would be a software module residing in the service provider's AAA 346 server. Alternatively the AAA gateway could be implemented as a 347 standalone process. 349 Figure 3 illustrates an AAA gateway. Communication type 4 is the 350 legacy protocol. Communication type 1 is the future standard AAA 351 protocol. And communication type 2 is for application specific 352 communication to Application Specific Modules (ASMs) or Service 353 Equipment. 355 +-------+ 356 | AAA |<---1---> to AAA server as in fig. 2 357 request <---4--->|GateWay| 358 | |<---2---> optionally to ASM/service 359 +-------+ 361 The numbers in the links denote types of communication. 363 Fig. 3 -- AAA Gateway for Legacy AAA Protocols 365 2.2.3. Interaction between the ASM and the Service 367 In a service provider, the Application Specific Module (ASM) and the 368 software providing the service itself may be tightly bound into a 369 single "Service Application". In this case, the interface between 370 them is just a software interface. But the service itself may be 371 provided by equipment external to the ASM, for example, a router in 372 the bandwidth broker application. In this case, the ASM communicates 373 with the service via some protocol. These two possibilities are 374 illustrated in figure 4. In both cases, we have labeled the 375 communication between the ASM and the service as communication type 376 5, which of course, is service specific. 378 | | 379 +--------------|----+ | 380 | Service 2 | 2 381 | Application | | | 382 | +-------------+ | +-------------+ 383 | | Application | | | Application | 384 | | Specific | | | Specific | 385 | | Module | | | Module | 386 | +-------------+ | +-------------+ 387 | | | | 388 | 5 | 5 389 | | | | 390 | +-------------+ | +-------------+ 391 | | Service | | | Service | 392 | | | | | Equipment | 393 | +-------------+ | +-------------+ 394 +-------------------+ 396 Fig. 4 -- ASM to Service Interaction (two views) 398 2.2.4. Multi-domain Architecture 400 The generic AAA server modules can use communication type 1 to 401 contact each other to evaluate parts of requests. Figure 5 402 illustrates a network of generic AAA servers in different 403 administrative domains communicating via communication type 1. 405 +-----+ 406 o--------| AAA |---->... 407 / | | 408 / +-----+\ 409 / | \+----+ 410 / +-----+ | RP | 411 / | ASM | +----+ 412 +--------+ +-----+ / | | 413 | Client |------| AAA |-------o +-----+ 414 +--------+ | | \ 415 +-----+\ \ 416 | \+----+ \ +-----+ 417 +-----+ | RP | o-----| AAA |---->... 418 | ASM | +----+ | | 419 | | +-----+\ 420 +-----+ | \+----+ 421 +-----+ | RP | 422 | ASM | +----+ 423 | | 424 +-----+ 426 The AAA servers use only communication type 1 to communicate. 427 ASM = Application Specific Module 428 RP = Repository 430 Fig. 5 -- Multi-domain Multi-type of Service Architecture 432 2.3. Model Observations 434 Some key points of the generic architecture are: 436 1) The same generic AAA server can function in all three 437 authorization models: agent, pull, and push [2]. 439 2) The rule based engine knows how to evaluate logical formulas and 440 how to parse AAA requests. 442 3) The Generic AAA server has no knowledge whatsoever about the 443 application specific services so the application specific 444 information it forwards is opaque to it. 446 4) Communication types 1, 2, and 3 each present their own naming 447 space problems. Solving these problems is fundamental to 448 forwarding AAA messages, locating application specific entities, 449 and locating applicable rules in the rule repositories. 451 5) A standard AAA protocol for use in communication type 1 should be 452 a peer-to-peer protocol without imposing client and server roles 453 on the communicating entities. 455 6) A standard AAA protocol should allow information units for 456 multiple different services belonging to multiple different 457 applications in multiple different administrative domains to be 458 combined in a single AAA protocol message. 460 2.4. Suggestions for Future Work 462 It is hoped that by using this generic model it will be feasible to 463 design a AAA protocol that is "future proof", in a sense, because 464 much of what we do not think about now can be encoded as application 465 specific information and referenced by policy rules stored in a 466 policy repository. From this model, some generic requirements arise 467 that will require some further study. For example, suppose a new 468 user is told that somewhere on a specific AAA server a certain 469 authorization can be obtained. The user will need a AAA protocol 470 that can: 472 1) send a query to find out which authorizations can be obtained from 473 a specific server, 475 2) provide a mechanism for determining what components must be put in 476 an AAA request for a specific authorization, and 478 3) formulate and transmit the authorization request. 480 Some areas where further work is particularly needed are in 481 identifying and designing the generic components of a AAA protocol 482 and in determining the basis upon which component forwarding and 483 policy retrieval decisions are made. 485 In addition to these areas, there is a need to explore the management 486 of rules in a multi-domain AAA environment because the development 487 and future deployment of a generic multi-domain AAA infrastructure is 488 largely dependent on its manageability. Multi-domain AAA 489 environments housing many rules distributed over several AAA servers 490 quickly become unmanageable if there is not some form of automated 491 rule creation and housekeeping. Organizations that allow their 492 services to be governed by rules, based on some form of commercial 493 contract, require the contract to be implemented with the least 494 possible effort. This can, for example, be achieved in a scalable 495 fashion if the individual user or user organization requesting a 496 service is able to establish the service itself. This kind of 497 interaction requires policy rule establishment between AAA servers 498 belonging to multiple autonomous administrative domains. 500 3. Layered AAA Protocol Model 502 In the previous section, we proposed the idea of a generic AAA server 503 with an interface to one or more Application Specific Modules (ASMs). 504 The generic server would handle many common functions including the 505 forwarding of AAA messages between servers in different 506 administrative domains. We envision message transport, hop-by-hop 507 security, and message forwarding as clearly being functions of the 508 generic server. The application specific modules would handle all 509 application specific tasks such as communication with service 510 equipment and access to special purpose databases. Between these two 511 sets of functions is another set of functions that presumably could 512 take place in either the generic server or an ASM or possibly by a 513 collaboration of both. These functions include the evaluation of 514 authorization rules against data that may reside in various places 515 including attributes from the authorization request itself. The more 516 we can push these functions down into the generic server, the more 517 powerful the generic server can be and the simpler the ASMs can be. 519 One way of organizing the different functions mentioned above would 520 be to assign them to a layered hierarchy. In fact, we have found the 521 layer paradigm to be a useful one in understanding AAA functionality. 522 This section explores the use of a layered hierarchy consisting of 523 the following AAA layers as a way of organizing the AAA functions: 525 Application Specific Service Layer 526 Presentation Service Layer 527 Transaction/Session Management Service Layer 528 Reliable/Secure Transport Service Layer 530 Nevertheless, the interface between the generic AAA server and the 531 ASMs proposed in the previous section may be more complex than a 532 simple layered model would allow. Even the division of functionality 533 proposed in this section goes beyond a strict understanding of 534 layering. Therefore this paper can probably best be understood as 535 the beginnings of a work to understand and organize the common 536 functionality required for a general purpose AAA infrastructure 537 rather than as a mature reference model for the creation of AAA 538 protocols. 540 In our view of AAA services modeled as a hierarchy of service layers, 541 there is a set of distributed processes at each service layer that 542 cooperate and are responsible for implementing that service layer's 543 functions. These processes communicate with each other using a 544 protocol specialized to carry out the functions and responsibilities 545 assigned to their service layer. The protocol at service layer n 546 communicates to its peers by depending on the services available to 547 it from service layer n-1. The service layer n also has a protocol 548 end point address space, through which the peer processes at service 549 layer n can send messages to each other. Together, these AAA service 550 layers can be assembled into an AAA protocol stack. 552 The advantage of this approach is that there is not just one 553 monolithic "AAA protocol". Instead there is a suite of protocols, 554 and each one is optimized to solve the problems found at its layer of 555 the AAA protocol stack hierarchy. 557 This approach realizes several key benefits: 559 - The protocol used at any particular layer in the protocol stack 560 can be substituted for another functionally equivalent protocol 561 without disrupting the services in adjacent layers. 563 - Requirements in one layer may be met without impact on protocols 564 operating in other layers. For example, local security 565 requirements may dictate the substitution of stronger or weaker 566 "reliable secure transport" layer security algorithms or 567 protocols. These can be introduced with no change or awareness of 568 the substitution by the layers above the Reliable/Secure Transport 569 layer. 571 - The protocol used for a given layer is simpler because it is 572 focused on a specific narrow problem that is assigned to its 573 service layer. In particular, it should be feasible to leverage 574 existing protocol designs for some aspects of this protocol stack 575 (e.g. CORBA GIOP/CDR for the presentation layer). 577 - A legacy AAA protocol message (e.g. a RADIUS message) can be 578 encapsulated within the protocol message(s) of a lower layer 579 protocol, preserving the investment of a Service Provider or User 580 Home Organization in their existing AAA infrastructure. 582 - At each service layer, a suite of alternatives can be designed, 583 and the service layer above it can choose which alternative makes 584 sense for a given application. However, it should be a primary 585 goal of the AAA protocol standardization effort to specify one 586 mandatory to implement protocol at the AAA Transaction/Session 587 Management (AAA-TSM) service layer (see section 3.4). 589 3.1. Elements of a Layered Architecture 591 At each layer of a layered architecture, a number of elements need to 592 be defined. These elements are discussed in the following sections. 594 3.1.1. Service Layer Abstract Interface Primitives 596 The service layer n is assumed to present a program interface through 597 which its adjacent service layer n+1 can access its services. The 598 types of abstract program service primitives and associated 599 parameters exchanged across the boundary between these service layers 600 must be specified. 602 3.1.2. Service Layer Peer End Point Name Space 604 Each service layer is treated as a set of cooperating processes 605 distributed across multiple computing systems. The service layer 606 must manage an end point name space that identifies these peer 607 processes. The conventions by which a service layer assigns a unique 608 end point name to each such peer process must be specified. 610 3.1.3. Peer Registration, Discovery, and Location Resolution 612 Along with defining an end point name space, a service layer must 613 also specify how its peers: 615 - announce their presence and availability, 617 - discover one another when they first begin operation, and 619 - detect loss of connectivity or service withdrawal. 621 It is also necessary to specify what mechanisms, if any, exist to 622 resolve a set of service layer specific search attributes into one or 623 more peer end point names that match the search criteria. 625 3.1.4. Trust Relationships Between Peer End Points 627 Once an end point has established its initial contact with another 628 peer, it must decide what authentication policy to adapt. It can 629 trust whatever authentication was done on its behalf by a lower 630 service layer or, through a pre-provisioning process, implicitly 631 trust the peer, or else go through an authentication process with its 632 peer. The supported mechanisms for establishing a service layer's 633 end point trust relationships must be specified. 635 3.1.5. Service Layer Finite State Machine 637 To the extent that a service layer's internal states are externally 638 visible, the layer's behavior in terms of a Finite State Machine 639 (FSM) should be specified. Events that can drive the FSM state 640 transitions may include: 642 - service layer n+1 interface primitive requests 644 - protocol data unit arrivals from peer service layer n end points 645 received through the layer n-1 access point 647 - service layer n-1 interface primitives (e.g. call backs or 648 interrupts) 650 - timer expirations 652 3.1.6. Protocol Data Unit Types 654 Each service layer defines a lexicon of protocol data units (PDUs) 655 that communicate between the layer's peer processes the information 656 that controls and/or monitors that service layer's distributed state 657 and allows the service processes of that layer to perform their 658 functions. Embedded in the PDUs of each layer are the PDUs of the 659 higher layers which depend on its services. The PDUs of each service 660 layer must be specified. 662 3.2. AAA Application Specific Service Layer 664 AAA applications have almost unlimited diversity, but imposing some 665 constraints and commonality is required for them to participate in 666 this generic AAA architectural framework. To satisfy these 667 constraints, participating AAA applications would derive their 668 application specific program logic from a standardized "Authorization 669 Server" abstract base object class. They would also support an 670 "Authorized Session" object class. An Authorization Session object 671 instance represents an approved authorization request that has a 672 long-lived allocation of services or resources. The generic AAA 673 architecture could be extended to include other abstract base object 674 classes in the future (e.g. Authorization Reservation, Authentication 675 Server, etc.). How to implement the derived Authorization Server 676 class's public methods for a given problem domain is entirely up to 677 the application. One technique might be to place a software 678 "wrapper" around an existing embedded application specific service to 679 adapt it to the standardized Authorization Server object paradigm. 680 The major Authorization Server class methods are: 682 - Publish an advertisement that describes the Authorization Server's 683 service attributes and its application specific service layer end 684 point address. Once the Authorization Server has registered, peer 685 processes can discover its presence or send messages addressed to 686 it. 688 - Application Specific Authorization Decision Function (AS-ADF) 689 method takes a User's application specific authorization request 690 and returns a decision of approve, deny, or conditionally approve 691 with referral to another stakeholder. In the latter case, the 692 application may create a reservation for the requested services or 693 resources. This method represents the "condition" side of a 694 policy rule's condition/ action pair. 696 - Commit a service or set of resources to a previously conditionally 697 approved authorization decision. For those authorization requests 698 that have a long-term lifecycle (as opposed to being 699 transactions), this method mobilizes a reservation into an 700 Authorized Session object instance. This method represents the 701 "action" side of a policy rule's condition/action pair. 703 - Cancel a previously conditionally approved Authorization request. 704 This method releases any associated reservations for services or 705 resources. 707 - Withdraw the Authorization Server's service advertisement. 709 A key motivation for structuring an AAA application as an 710 Authorization Server object instance is to separate the generic 711 authorization decision logic from the application-specific 712 authorization decision logic. In many cases, the application can be 713 divorced from the AAA problem altogether, and its AAA responsibility 714 can be assigned to an external rules based generic AAA Server. (The 715 idea is similar to that of a trust management policy server as 716 defined in [5].) This would facilitate a security administrator 717 deploying AAA policy in a central repository. The AAA policy is 718 applied consistently across all users of the applications, resources, 719 and services controlled by the AAA server. However, it is recognized 720 that for many problem domains, there are unique rules intrinsic to 721 the application. In these cases, the generic AAA Server must refer 722 the User's authorization request to the relevant Application Specific 723 Module. 725 3.3. Presentation Service Layer 727 The presentation service layer solves the data representation 728 problems that are encountered when communicating peers exchange 729 complex data structures or objects between their heterogeneous 730 computing systems. The goal is to transfer semantically equivalent 731 application layer data structures regardless of the local machine 732 architecture, operating system, compiler, or other potential inter- 733 system differences. 735 One way to better understand the role of the presentation layer is to 736 evaluate an existing example. The Generic Inter-ORB Protocol (GIOP) 737 and its Common Data Representation (CDR) is a presentation service 738 layer protocol developed by the Object Management Group (OMG) 739 industry consortium. GIOP is one component within the Common Object 740 Request Broker Architecture (CORBA). Peer Object Request Brokers 741 (ORB) executing on heterogeneous systems use GIOP to invoke remote 742 CORBA object interface methods. GIOP encodes an object method's 743 input and output parameters in the Common Data Representation (CDR). 744 While there are other presentation service layer protocols in the 745 industry, GIOP in combination with CDR represents a mature, 746 comprehensive solution that exhibits many of the presentation service 747 layer requirements that are applicable within the AAA protocol model. 749 In the context of Internet access AAA protocols, RADIUS and its 750 successors use the Attribute Value Pair (AVP) paradigm as the 751 presentation service layer encoding scheme. While such an approach 752 is versatile, it is also prone to becoming splintered into many ad 753 hoc and vendor specific dialects. There is no structure imposed or 754 method to negotiate the constraints on which AVPs are combined and 755 interpreted for a given conversation in a consistent way across AAA 756 protocol implementations or problem domains. At run-time, it can be 757 hard for the communicating peers to negotiate to a common inter- 758 operable set of AVPs. 760 To avoid this pitfall, a primary presentation service layer 761 responsibility is the ability to let peers negotiate from a base 762 Authorization Server object class towards a commonly understood 763 derived Authorization Server object class that both presentation 764 service layer peers have implemented for their application specific 765 problem domain. This negotiation implies a requirement for a 766 globally registered and maintained presentation service layer 767 hierarchy of Authorization Server object class names. 769 3.4. AAA Transaction/Session Management Service Layer 771 The AAA Transaction/Session Management (AAA-TSM) service layer is a 772 distributed set of AAA Servers, which typically reside in different 773 administrative domains. Collectively they are responsible for the 774 following three services: 776 Authentication -- Execute the procedure(s) needed to confirm the 777 identity of the other parties with which the AAA TSM entity has a 778 trust relationship. 780 Authorization -- Make an authorization decision to grant or deny a 781 User's request for services or resources. The generic rules based 782 policy engine described earlier in this document executes the 783 authorization decision function. When the User's request is 784 instantaneous and transient, then its authorization approval is 785 treated as an ephemeral transaction. If the authorization 786 approval implies a sustained consumption of a service or 787 resources, then the request is transformed into an Authorized 788 Session. For the duration of the Authorized Session's lifetime: 790 - its state may be queried and reported, or 792 - it may be canceled before service is completed, or 794 - the service being delivered may be modified to operate under 795 new parameters and conditions, or 797 - the service may complete on its own accord. 799 In each of these cases, the AAA-TSM service layer must synchronize 800 the Authorized Session's distributed state across all of those AAA 801 Servers which are implementing that specific Authorized Session. 803 Accounting -- Generate any relevant accounting information regarding 804 the authorization decision and the associated Authorized Session 805 (if any) that represents the ongoing consumption of those services 806 or resources. 808 The peer AAA servers and their AAA-TSM end points exchange AAA-TSM 809 messages to realize these AAA functions. A central AAA-TSM concept 810 is that there is a set of one or more AAA Server stakeholders who are 811 solicited to approve/disapprove a User request for application layer 812 services. The AAA-TSM service layer routes the User's request from 813 one stakeholder to the next, accumulating the requisite approvals 814 until they have all been asked to make an authorization decision. 816 The AAA Servers may also do User authentication (or re- 817 authentication) as part of this approval process. The overall flow 818 of the routing from one stakeholder to another may take the form of 819 the "push", "pull", or "agent" authorization models developed in [2]. 820 However, in principle, it is feasible to have an arbitrary routing 821 path of an AAA-TSM authorization request among stakeholders. Once the 822 final approval is received, the AAA-TSM service layer commits the 823 requested service by notifying all of those stakeholders that require 824 a confirmation (i.e. turn on a pending reservation and do a 825 transaction commit). Alternatively, any stakeholder among those on 826 the consent list can veto the authorization request. In that case, 827 all stakeholders who previously approved the request and had asked 828 for a confirmation are told that the request has been denied (i.e., 829 cancel reservation and do a transaction rollback). 831 The AAA-TSM authorization request payload must carry its own "Context 832 State", such that when an AAA server receives it, there is sufficient 833 information that it is essentially self-contained. Embedding the 834 Context State within the AAA-TSM message provides two benefits. 835 First, the message can be immediately processed with respect to the 836 AAA Server's local policy, and this minimizes or altogether avoids 837 the need for the AAA Server to exchange additional AAA-TSM messages 838 with its peers to complete its piece of the overall authorization 839 decision. The other benefit is that the AAA Server minimizes the 840 amount of state information resources that it commits to a user's 841 pending request until it is fully approved. This helps protect 842 against denial of service attacks. 844 One can envision many possible message elements that could be part of 845 the Context State carried within an AAA-TSM request message: 847 - AAA-TSM session identifier, a unique handle representing this 848 authorization request. All AAA servers who participate in a 849 request's approval process and its subsequent monitoring 850 throughout its Session lifetime refer to this handle. 852 - permission lists stating which AAA Servers are allowed to modify 853 which parts of the message. 855 - User's authorization request, encoded as a presentation layer PDU. 857 - User authentication information, (e.g. an X.509 public key 858 certificate). 860 - User credentials information, or else a pointer to where that 861 information can be found by an AAA server. An example of such 862 credentials would be an X.509 attributes certificate. 864 - the list of AAA Server stakeholders who have yet to be visited to 865 gain full approval of the User's authorization request. Each 866 element in that list contains a presentation layer message 867 encoding how the user authorization request should be evaluated by 868 its application specific Authorization Decision Function (ADF). 870 - the current position in the list of AAA Server stakeholders to be 871 visited. 873 - a list of those AAA servers which have already conditionally 874 approved the User's authorization request, but which have 875 predicated their approval on the request also completing its 876 approval from those stakeholders who have not yet seen the 877 request. Each element in the list has a digital signature or 878 comparable mechanism by which their approval can be subsequently 879 verified. 881 - an expiration time stamp, expressed in a universally understood 882 time 884 reference, which sets a lifetime limit on the AAA-TSM message's 885 validity. This offers some replay attack protection, and inhibits 886 messages from circulating indefinitely seeking the completion of a 887 request's approval. 889 - a message payload modification audit trail, tracing which parties 890 introduced changes into the User's authorization request terms and 891 conditions. 893 - an AAA-TSM message integrity check, computed across the whole 894 message rather than its individual elements, and signed by the 895 most recent AAA-TSM layer end point process to modify the AAA-TSM 896 message before its transmission to its AAA-TSM peer. This 897 function may be delegated to the underlying Reliable Secure 898 Transport layer connection to that destination peer. 900 3.5. AAA-TSM Service Layer Program Interface Primitives 902 The AAA-TSM service layer and its adjacent presentation service layer 903 communicate across their boundary through a set of program interface 904 primitives. A key design goal is to keep these primitives the same 905 regardless of the higher level AAA application, analogous to a 906 callable "plug-in". The two service layers are responsible for 907 coordinating their state information. This responsibility includes 908 all of the pending Authorization requests and the Authorization 909 Sessions that they are both controlling and monitoring. The initial 910 contact between these two layers is through an abstract object that 911 is called an AAA-TSM Service Access Point (SAP). A particular 912 service instance between these two layers is realized in an abstract 913 object that is called an Authorized Session. The presentation 914 service layer invokes AAA-TSM interface primitives against an AAA-TSM 915 SAP. 917 The AAA-TSM service layer interface primitives can be broadly 918 characterized as follows: 920 - Register a presentation end point address identifier and its 921 associated set of attributes to a service access point. 923 - Send a presentation layer message to a specified destination 924 presentation layer peer end point address. 926 - Receive a presentation layer message from another presentation 927 layer end point address. A receive operation may select a 928 specific originating presentation layer end point address from 929 which the message is expected, or receive a message from any 930 presentation layer peer. 932 - The AAA-TSM service layer calls an application specific 933 authorization decision function, which returns a condition code 934 expressing an approval, denial, or partially approves with a 935 referral to another AAA Server. 937 - AAA-TSM service layer tells the presentation layer to commit an 938 earlier partially approved authorization request. 940 - Cancel an earlier partially approved authorization request (i.e. 941 rollback). 943 - The presentation service layer notifies the AAA-TSM service layer 944 that it has terminated an in-progress Authorized Session. 946 - AAA-TSM service layer notifies the presentation service layer that 947 another presentation service layer peer has terminated an 948 Authorized Session. 950 - Un-register a presentation service layer end point address. 952 3.6. AAA-TSM Layer End Point Name Space 954 The AAA-TSM service layer end point name space is the N-tuple formed 955 by concatenating the following components: 957 - AAA Server's Reliable/Secure Transport layer end point address 959 - AAA-TSM authorization request serial number, a unique durable 960 unsigned integer generated by the AAA Server who first receives 961 the User's authorization request. 963 Some AAA applications may require that each assigned AAA-TSM 964 transaction serial number be stored in persistent storage, and 965 require that it be recoverable across AAA Server system re-boots. 966 The serial number generation algorithm must be guaranteed unique even 967 if the AAA Server does a re-boot. 969 3.7. Protocol Stack Examples 971 The layering paradigm makes it possible to use the most appropriate 972 syntax for each application for encoding the Application Specific 973 Information units of that application. This encoding would take 974 place at the presentation layer. Similarly the application layer can 975 recognize the semantics specific to each application. Figure 6 976 illustrates some possible AAA protocol stacks. 978 +------------++------------++-----------++-----------++----------+ 979 | || Application|| E-Commerce|| Bandwidth || Roaming &| 980 | AAA || specific || Internet || Broker || mobile IP| 981 | Application||object class|| Open ||cross-admin|| remote | 982 | Service || interface || Trading || domain || access | 983 | Layer ||specified in|| Protocol || COPS || AVP | 984 | || CORBA IDL || (IOTP) || extensions|| lexicons | 985 +------------++------------++-----------++-----------++----------+ 986 | || CORBA ||Extensible || Common || DIAMETER | 987 |Presentation|| Generic || Markup || Open || or | 988 | Service || Inter-ORB || Language || Policy || RADIUS | 989 | Layer || Protocol || (XML) ||Specificatn||Attribute | 990 | || (GIOP) || || (COPS) ||Value/Pair| 991 +------------++------------++-----------++-----------++----------+ 992 | AAA-TSM Service Layer Application Program Interface (API) | 993 +----------------------------------------------------------------+ 994 | AAA Transaction/Session Management (AAA-TSM) Service Layer | 995 +----------------------------------------------------------------+ 996 | Reliable Secure Transport Layer | 997 +----------------------------------------------------------------+ 999 Fig. 6 -- Possible AAA Protocol Stacks 1001 4. Security Considerations 1003 Security considerations for the framework on which the work described 1004 in this memo is based are discussed in [2]. Security requirements 1005 for authorization are listed in section 2.2 of [3]. 1007 This memo identifies a basic set of AAA functions that are general in 1008 nature and common to many different AAA applications. We propose 1009 that a standard set of security mechanisms should be defined as part 1010 of a base AAA protocol which would include such things as public key 1011 encryption and digital signatures that could be applied to individual 1012 information units within an AAA message. Security with this 1013 granularity is needed to meet the end-to-end security requirement 1014 specified in section 2.2.7 of [3] because a single AAA message may 1015 contain multiple information units each generated by AAA servers from 1016 different administrative domains and destined to AAA servers in 1017 different domains. 1019 In addition, it may be necessary to encrypt or sign an entire AAA 1020 message on a hop-by-hop basis. This could be handled by a standard, 1021 lower layer protocol such as IPSEC. If so, then certain auditing 1022 requirements will have to be met so that it can be established later 1023 that the messages relative to some specific session ID were, in fact, 1024 protected in a particular way. Alternatively, hop-by-hop security 1025 mechanisms may be built into the base AAA protocol itself. 1027 Glossary 1029 Application Specific Information (ASI) -- information in an AAA 1030 protocol message that is specific to a particular application. 1032 Application Specific Module (ASM) -- a software module that 1033 implements a program interface to a generic AAA server which 1034 handles application specific functionality for an AAA protocol 1035 message. 1037 Service Provider -- an organization which provides a service. 1039 User -- the entity seeking authorization to use a resource or a 1040 service. 1042 User Home Organization (UHO) -- An organization with whom the User 1043 has a contractual relationship which can authenticate the User and 1044 may be able to authorize access to resources or services. 1046 References 1048 [1] Bradner, Scott, "The Internet Standards Process -- Revision 3", 1049 RFC 2026, BCP 9, October 1996. 1051 [2] Vollbrecht, John, et al, "AAA Authorization Framework", draft- 1052 irtf-aaaarch-authorization-framework-01.txt, March 2000. 1054 [3] Vollbrecht, John, et al, "AAA Authorization Application 1055 Examples", draft-irtf-aaaarch-authorization-apps-01.txt, March 1056 2000. 1058 [4] Vollbrecht, John, et al, "AAA Authorization Requirements", 1059 draft-irtf-aaaarch-authorization-reqs-01.txt, March 2000. 1061 [5] Blaze, Matt et al, "The KeyNote Trust-Management System Version 1062 2", RFC 2704, September 1999. 1064 Authors' Addresses 1065 Cees T.A.M. de Laat 1066 Physics and Astronomy dept. 1067 Utrecht University 1068 Pincetonplein 5, 1069 3584CC Utrecht 1070 Netherlands 1072 Phone: +31 30 2534585 1073 Phone: +31 30 2537555 1074 EMail: delaat@phys.uu.nl 1076 George M. Gross 1077 Lucent Technologies 1078 184 Liberty Corner Road, m.s. LC2N-D13 1079 Warren, NJ 07059 1080 USA 1082 Phone: +1 908 580 4589 1083 Fax: +1 908 580 7430 1084 Email: gmgross@lucent.com 1086 Leon Gommans 1087 Cabletron Systems EMEA 1088 Kerkplein 24 1089 2841 XM Moordrecht 1090 The Netherlands 1092 Phone: +31 182 379278 1093 Email: gommans@cabletron.com 1095 John R. Vollbrecht 1096 Merit Network, Inc. 1097 4251 Plymouth Rd., Suite 2000 1098 Ann Arbor, MI 48105 1099 USA 1101 Phone: +1 734 763 1206 1102 Fax: +1 734 647 3745 1103 EMail: jrv@merit.edu 1105 David W. Spence 1106 Merit Network, Inc. 1107 4251 Plymouth Rd., Suite 2000 1108 Ann Arbor, MI 48105 1109 USA 1111 Phone: +1 734 615 2630 1112 Fax: +1 734 647 3745 1113 EMail: dwspence@merit.edu