diff options
Diffstat (limited to 'doc/rfc/rfc2903.txt')
| -rw-r--r-- | doc/rfc/rfc2903.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc2903.txt b/doc/rfc/rfc2903.txt new file mode 100644 index 0000000..44fe067 --- /dev/null +++ b/doc/rfc/rfc2903.txt @@ -0,0 +1,1459 @@ + + + + + + +Network Working Group C. de Laat +Request for Comments: 2903 Utrecht University +Category: Experimental G. Gross + Lucent Technologies + L. Gommans + Enterasys Networks EMEA + J. Vollbrecht + D. Spence + Interlink Networks, Inc. + August 2000 + + + Generic AAA Architecture + +Status of this Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Abstract + + This memo proposes an Authentication, Authorization, Accounting (AAA) + architecture that would incorporate a generic AAA server along with + an application interface to a set of Application Specific Modules + that could perform application specific AAA functions. A separation + of AAA functions required in a multi-domain environment is then + proposed using a layered protocol abstraction. The long term goal is + to create a generic framework which allows complex authorizations to + be realized through a network of interconnected AAA servers. + + + + + + + + + + + + + + + + +de Laat, et al. Experimental [Page 1] + +RFC 2903 Generic AAA Architecture August 2000 + + +Table of Contents + + 1. Introduction ................................................ 2 + 2. Generic AAA Architecture .................................... 4 + 2.1. Architectural Components of a Generic AAA Server ....... 4 + 2.1.1. Authorization Rule Evaluation ................... 4 + 2.1.2. Application Specific Module (ASM) ............... 5 + 2.1.3. Authorization Event Log ......................... 6 + 2.1.4. Policy Repository ............................... 6 + 2.1.5. Request Forwarding .............................. 6 + 2.2. Generic AAA Server Model ............................... 6 + 2.2.1. Generic AAA Server Interactions ................. 7 + 2.2.2. Compatibility with Legacy Protocols ............. 7 + 2.2.3. Interaction between the ASM and the Service ..... 9 + 2.2.4. Multi-domain Architecture ....................... 10 + 2.3. Model Observations ..................................... 10 + 2.4. Suggestions for Future Work ............................ 11 + 3. Layered AAA Protocol Model .................................. 12 + 3.1. Elements of a Layered Architecture ..................... 14 + 3.1.1. Service Layer Abstract Interface Primitives ..... 14 + 3.1.2. Service Layer Peer End Point Name Space ......... 14 + 3.1.3. Peer Registration, Discovery, and Location + Resolution ............................................. 14 + 3.1.4. Trust Relationships Between Peer End Points ..... 14 + 3.1.5. Service Layer Finite State Machine .............. 15 + 3.1.6. Protocol Data Unit Types ........................ 15 + 3.2. AAA Application Specific Service Layer ................. 15 + 3.3. Presentation Service Layer ............................. 16 + 3.4. AAA Transaction/Session Management Service Layer ....... 17 + 3.5. AAA-TSM Service Layer Program Interface Primitives ..... 20 + 3.6. AAA-TSM Layer End Point Name Space ..................... 21 + 3.7. Protocol Stack Examples ................................ 22 + 4. Security Considerations ..................................... 22 + Glossary ....................................................... 23 + References ..................................................... 24 + Authors' Addresses ............................................. 24 + Full Copyright Statement ....................................... 26 + +1. Introduction + + The work for this memo was done by a group that originally was the + Authorization subgroup of the AAA Working Group of the IETF. When + the charter of the AAA working group was changed to focus on MobileIP + and NAS requirements, the AAAarch Research Group was chartered within + the IRTF to continue and expand the architectural work started by the + Authorization subgroup. This memo is one of four which were created + by the subgroup. This memo is a starting point for further work + within the AAAarch Research Group. It is still a work in progress + + + +de Laat, et al. Experimental [Page 2] + +RFC 2903 Generic AAA Architecture August 2000 + + + and is published so that the work will be available for the AAAarch + subgroup and others working in this area, not as a definitive + description of architecture or requirements. + + The authorization subgroup of the AAA Working Group proposed an "AAA + Authorization Framework" [2] illustrated with numerous application + examples [3] which in turn motivates a proposed list of authorization + requirements [4]. This memo builds on the framework presented in [2] + by proposing an AAA infrastructure consisting of a network of + cooperating generic AAA servers communicating via a standard + protocol. The protocol should be quite general and should support + the needs of a wide variety of applications requiring AAA + functionality. To realize this goal, the protocol will need to + operate in a multi-domain environment with multiple service providers + as well as entities taking on other AAA roles such as User Home + Organizations and brokers. It should be possible to combine requests + for multiple authorizations of different types in the same + authorization transaction. The AAA infrastructure will be required + to forward the components of such requests to the appropriate AAA + servers for authorization and to collect the authorization decisions + from the various AAA servers consulted. All of this activity is + perfectly general in nature and can be realized in the common + infrastructure. + + But the applications requiring AAA services will each have their own + unique needs. After a service is authorized, it must be configured + and initialized. This will require application specific knowledge + and may require application specific protocols to communicate with + application specific service components. To handle these application + specific functions, we propose an application interface between a + generic AAA server and a set of one or more Application Specific + Modules (ASMs) which can carry out the unique functionality required + by each application. + + Since the data required by each application for authentication, + authorization, or accounting may have unique structure, the standard + AAA protocol should allow the encapsulation of opaque units of + Application Specific Information (ASI). These units would begin with + a standard header to allow them to be forwarded by the generic + infrastructure. When delivered to the final destination, an ASI unit + would be passed by a generic AAA server across its program interface + to an appropriate ASM for application specific processing. + Nevertheless, it remains a goal of the design for information units + to be encoded in standard ways as much as possible so as to enable + processing by a generic rule based engine. + + + + + + +de Laat, et al. Experimental [Page 3] + +RFC 2903 Generic AAA Architecture August 2000 + + + The interactions of the generic AAA server with the Application + Specific Modules and with each other to realize complex AAA functions + is explored in section 2. Then, in section 3, we attempt to further + organize the AAA functions into logical groups using a protocol + layering abstraction. This abstraction is not intended to be a + reference model ready to be used for protocol design. At this point + in the work, there are numerous questions that need to be addressed + and numerous problems that remain to be solved. It may be that an + abstraction other than layering will prove to be more useful or, more + likely, that the application layer will require some substructure of + its own. + + Finally, in section 4, we show how the security requirements + identified in [4] can be met in the generic server and the + Application Specific Modules by applying security techniques such as + public key encryption or digital signatures to the Application + Specific Information units individually, so that different + stakeholders in the AAA server network can protect selected + information units from being deciphered or altered by other + stakeholders in an authentication, authorization, or accounting + chain. + +2. Generic AAA Architecture + + For the long term we envision a generic AAA server which is capable + of authenticating users, handling authorization requests, and + collecting accounting data. For a service provider, such a generic + AAA server would be interfaced to an application specific module + which manages the resource for which authorization is required. + Generic AAA components would also be deployed in other administrative + domains performing authorization functions. + +2.1. Architectural Components of a Generic AAA Server + +2.1.1. Authorization Rule Evaluation + + The first step in the authorization process is for the user or an + entity operating on the user's behalf to submit a well-formatted + request to an AAA server. A generic AAA server has rules (logic + and/or algebraic formulas) to inspect the request and come to an + authorization decision. The first problem which arises is that + Application Specific Information (ASI) has to be separated from the + underlying logic for the authorization. Ideally the AAA server would + have a rule based engine at this point which would know the logic + rules and understand some generic information in the request, but it + would not know anything about application specific information except + where this information can be evaluated to give a boolean or + numerical value. It should be possible to create rules that refer to + + + +de Laat, et al. Experimental [Page 4] + +RFC 2903 Generic AAA Architecture August 2000 + + + data elements that were not considered when the application was + created. For example, one could request to do a remote virtual + control room experiment from home using a dialin provider. The + request would only be successful if the dialin access server allows + it and if there is bandwidth available (bandwidth broker) and if the + experimenter has the money to pay for it (E-Commerce). Possibly the + people who specified the bandwidth broker protocol did not think of + combining quality of service with a network service authorization in + a single AAA request, but this generic model would allow it. + + +------+ +-------+ +-------+ +-------+ +-------+ + | | auth | | auth | | auth | | auth | | + | |<---->| AAA |<---->| AAA |<---->| AAA |<---->| AAA | + | | | | | | | | | | + | | +-------+ +-------+ +-------+ +-------+ + | User | | | | | + | | | +-------+ +-------+ +-------+ + | | | | BB | | BB | |Budget | + | | | +-------+ +-------+ +-------+ + | | | | | + | | +-------+ | | + | | |dial in| +-------+ +-------+ + | |<====>|service|<====>|network|<====>|network|<===> Experiment + +------+ +-------+ +-------+ +-------+ + + user <-> dialin <-> backbone with BB <-> <remote experiment> + + Fig. 1 -- Example of a Multi Domain Multi Type of Server Request + +2.1.2. Application Specific Module (ASM) + + Ultimately an AAA server needs to interact with an application + specific module (ASM). In a service provider, the ASM would manage + resources and configure the service equipment to provide the + authorized service. It might also involve itself in the + authorization decision because it has the application specific + knowledge required. A user home organization (UHO) may require ASMs + as well, to perform application specific user authorization + functions. For example, a UHO ASM might be required to access + certain application specific databases or interpret application + specific service level specifications. + + Whatever the role of an administration relative to an authorization + decision, the capabilities of the generic AAA server and the + interface between it and the ASMs remains the same. This interface + may be an Application Program Interface (API) or could even be a + protocol based interface. In this model, however, the application + + + + +de Laat, et al. Experimental [Page 5] + +RFC 2903 Generic AAA Architecture August 2000 + + + specific module is regarded as as separate architectural component + from the generic AAA server. As such, it must be addressable and + must therefore be part of a global naming space. + +2.1.3. Authorization Event Log + + For auditing purposes, the generic server must have some form of + database to store time-stamped events which occur in the AAA server. + This database can be used to account for authorizations which were + given, but it can also be used in rules. One can imagine rules in + which an authorization is only given if some other event was logged + in the past. With the aid of certificates, this database could + support non-repudiation. + +2.1.4. Policy Repository + + A database containing the available services and resources about + which authorization decisions can be made and the policy rules to + make them is also needed. Here too, the naming space for the + services and resources is important since they must be addressable + from other AAA servers to be able to build complex authorization + requests. + +2.1.5. Request Forwarding + + Due to the multiple administrative domain (multi-kingdom) nature of + the AAA problem, a mechanism to forward messages between AAA servers + is needed. The protocol by which two AAA servers communicate should + be a peer-to-peer protocol. + +2.2. Generic AAA Server Model + + With the implementation of the above mentioned components, the AAA + server would be able to handle AAA requests. It would inspect the + contents of the request, determine what authorization is requested, + retrieve the policy rules from the repository, perform various local + functions, and then choose one of the following options to further + process each of the components of the request: + + a) Let the component be evaluated by an attached ASM. + + b) Query the authorization event log or the policy repository for the + answer. + + c) Forward the component(s) to another AAA server for evaluation. + + In the following sections we present the generic model. + + + + +de Laat, et al. Experimental [Page 6] + +RFC 2903 Generic AAA Architecture August 2000 + + +2.2.1. Generic AAA Server Interactions + + Figure 2 illustrates a generic AAA Server with connections to the + various architectural components described above. In this model, the + user or another AAA server contacts the AAA server to get + authorization, and the AAA server interacts with the service. The + request is sent to the AAA server using the future AAA protocol. The + server interacts with the service via a second protocol which we have + labeled as type "2" in the figure. We say no more of the type 2 + protocol than that it must support some global naming space for the + application specific items. The same holds for the type 3 + communication used to access the repository. + + +------------------+ + | | + request <-----1----->|Generic AAA Server|<---1---> AAA server + |Rule based engine | + | |\ + +------------------+ 3 +------------+ + ^ \| Policy and | + | | event | + 2 | repository | + | +------------+ + v + +------------------+ + | Application | + | Specific | + | Module | + +------------------+ + + The numbers in the links denote types of communication. + + Fig. 2 -- Generic AAA Server Interactions + +2.2.2. Compatibility with Legacy Protocols + + Because of the widespread deployment of equipment that implements + legacy AAA protocols and the desire to realize the functionality of + the new AAA protocol while protecting the investment in existing + infrastructure, it may be useful to implement a AAA gateway function + that can encapsulate legacy protocol data units within the messages + of the new protocol. Use of this technique, for example, would allow + Radius attribute value pairs to be encapsulated in Application + Specific Information (ASI) units of the new protocol in such a way + that the ASI units can be digitally signed and encrypted for end-to- + end protection between a service provider's AAA server and a home AAA + server communicating via a marginally trusted proxy AAA server. The + service provider's NAS would communicate via Radius to the service + + + +de Laat, et al. Experimental [Page 7] + +RFC 2903 Generic AAA Architecture August 2000 + + + provider's AAA server, but the AAA servers would communicate among + themselves via the new AAA protocol. In this case, the AAA gateway + would be a software module residing in the service provider's AAA + server. Alternatively the AAA gateway could be implemented as a + standalone process. + + Figure 3 illustrates an AAA gateway. Communication type 4 is the + legacy protocol. Communication type 1 is the future standard AAA + protocol. And communication type 2 is for application specific + communication to Application Specific Modules (ASMs) or Service + Equipment. + + +-------+ + | AAA |<---1---> to AAA server as in fig. 2 + request <---4--->|GateWay| + | |<---2---> optionally to ASM/service + +-------+ + + The numbers in the links denote types of communication. + + Fig. 3 -- AAA Gateway for Legacy AAA Protocols + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +de Laat, et al. Experimental [Page 8] + +RFC 2903 Generic AAA Architecture August 2000 + + +2.2.3. Interaction between the ASM and the Service + + In a service provider, the Application Specific Module (ASM) and the + software providing the service itself may be tightly bound into a + single "Service Application". In this case, the interface between + them is just a software interface. But the service itself may be + provided by equipment external to the ASM, for example, a router in + the bandwidth broker application. In this case, the ASM communicates + with the service via some protocol. These two possibilities are + illustrated in figure 4. In both cases, we have labeled the + communication between the ASM and the service as communication type + 5, which of course, is service specific. + + | | + +--------------|----+ | + | Service 2 | 2 + | Application | | | + | +-------------+ | +-------------+ + | | Application | | | Application | + | | Specific | | | Specific | + | | Module | | | Module | + | +-------------+ | +-------------+ + | | | | + | 5 | 5 + | | | | + | +-------------+ | +-------------+ + | | Service | | | Service | + | | | | | Equipment | + | +-------------+ | +-------------+ + +-------------------+ + + Fig. 4 -- ASM to Service Interaction (two views) + + + + + + + + + + + + + + + + + + + +de Laat, et al. Experimental [Page 9] + +RFC 2903 Generic AAA Architecture August 2000 + + +2.2.4. Multi-domain Architecture + + The generic AAA server modules can use communication type 1 to + contact each other to evaluate parts of requests. Figure 5 + illustrates a network of generic AAA servers in different + administrative domains communicating via communication type 1. + + +-----+ + o--------| AAA |---->... + / | | + / +-----+\ + / | \+----+ + / +-----+ | RP | + / | ASM | +----+ + +--------+ +-----+ / | | + | Client |------| AAA |-------o +-----+ + +--------+ | | \ + +-----+ \ + | +----+ \ +-----+ + +-----+ | RP | o-----| AAA |---->... + | ASM | +----+ | | + | | +-----+\ + +-----+ | \+----+ + +-----+ | RP | + | ASM | +----+ + | | + +-----+ + + The AAA servers use only communication type 1 to communicate. + ASM = Application Specific Module + RP = Repository + + Fig. 5 -- Multi-domain Multi-type of Service Architecture + +2.3. Model Observations + + Some key points of the generic architecture are: + + 1) The same generic AAA server can function in all three + authorization models: agent, pull, and push [2]. + + 2) The rule based engine knows how to evaluate logical formulas and + how to parse AAA requests. + + 3) The Generic AAA server has no knowledge whatsoever about the + application specific services so the application specific + information it forwards is opaque to it. + + + + +de Laat, et al. Experimental [Page 10] + +RFC 2903 Generic AAA Architecture August 2000 + + + 4) Communication types 1, 2, and 3 each present their own naming + space problems. Solving these problems is fundamental to + forwarding AAA messages, locating application specific entities, + and locating applicable rules in the rule repositories. + + 5) A standard AAA protocol for use in communication type 1 should be + a peer-to-peer protocol without imposing client and server roles + on the communicating entities. + + 6) A standard AAA protocol should allow information units for + multiple different services belonging to multiple different + applications in multiple different administrative domains to be + combined in a single AAA protocol message. + +2.4. Suggestions for Future Work + + It is hoped that by using this generic model it will be feasible to + design a AAA protocol that is "future proof", in a sense, because + much of what we do not think about now can be encoded as application + specific information and referenced by policy rules stored in a + policy repository. From this model, some generic requirements arise + that will require some further study. For example, suppose a new + user is told that somewhere on a specific AAA server a certain + authorization can be obtained. The user will need a AAA protocol + that can: + + 1) send a query to find out which authorizations can be obtained from + a specific server, + + 2) provide a mechanism for determining what components must be put in + an AAA request for a specific authorization, and + + 3) formulate and transmit the authorization request. + + Some areas where further work is particularly needed are in + identifying and designing the generic components of a AAA protocol + and in determining the basis upon which component forwarding and + policy retrieval decisions are made. + + In addition to these areas, there is a need to explore the management + of rules in a multi-domain AAA environment because the development + and future deployment of a generic multi-domain AAA infrastructure is + largely dependent on its manageability. Multi-domain AAA + environments housing many rules distributed over several AAA servers + quickly become unmanageable if there is not some form of automated + rule creation and housekeeping. Organizations that allow their + services to be governed by rules, based on some form of commercial + contract, require the contract to be implemented with the least + + + +de Laat, et al. Experimental [Page 11] + +RFC 2903 Generic AAA Architecture August 2000 + + + possible effort. This can, for example, be achieved in a scalable + fashion if the individual user or user organization requesting a + service is able to establish the service itself. This kind of + interaction requires policy rule establishment between AAA servers + belonging to multiple autonomous administrative domains. + +3. Layered AAA Protocol Model + + In the previous section, we proposed the idea of a generic AAA server + with an interface to one or more Application Specific Modules (ASMs). + The generic server would handle many common functions including the + forwarding of AAA messages between servers in different + administrative domains. We envision message transport, hop-by-hop + security, and message forwarding as clearly being functions of the + generic server. The application specific modules would handle all + application specific tasks such as communication with service + equipment and access to special purpose databases. Between these two + sets of functions is another set of functions that presumably could + take place in either the generic server or an ASM or possibly by a + collaboration of both. These functions include the evaluation of + authorization rules against data that may reside in various places + including attributes from the authorization request itself. The more + we can push these functions down into the generic server, the more + powerful the generic server can be and the simpler the ASMs can be. + + One way of organizing the different functions mentioned above would + be to assign them to a layered hierarchy. In fact, we have found the + layer paradigm to be a useful one in understanding AAA functionality. + This section explores the use of a layered hierarchy consisting of + the following AAA layers as a way of organizing the AAA functions: + + Application Specific Service Layer + Presentation Service Layer + Transaction/Session Management Service Layer + Reliable/Secure Transport Service Layer + + Nevertheless, the interface between the generic AAA server and the + ASMs proposed in the previous section may be more complex than a + simple layered model would allow. Even the division of functionality + proposed in this section goes beyond a strict understanding of + layering. Therefore this paper can probably best be understood as + the beginnings of a work to understand and organize the common + functionality required for a general purpose AAA infrastructure + rather than as a mature reference model for the creation of AAA + protocols. + + + + + + +de Laat, et al. Experimental [Page 12] + +RFC 2903 Generic AAA Architecture August 2000 + + + In our view of AAA services modeled as a hierarchy of service layers, + there is a set of distributed processes at each service layer that + cooperate and are responsible for implementing that service layer's + functions. These processes communicate with each other using a + protocol specialized to carry out the functions and responsibilities + assigned to their service layer. The protocol at service layer n + communicates to its peers by depending on the services available to + it from service layer n-1. The service layer n also has a protocol + end point address space, through which the peer processes at service + layer n can send messages to each other. Together, these AAA service + layers can be assembled into an AAA protocol stack. + + The advantage of this approach is that there is not just one + monolithic "AAA protocol". Instead there is a suite of protocols, + and each one is optimized to solve the problems found at its layer of + the AAA protocol stack hierarchy. + + This approach realizes several key benefits: + + - The protocol used at any particular layer in the protocol stack + can be substituted for another functionally equivalent protocol + without disrupting the services in adjacent layers. + + - Requirements in one layer may be met without impact on protocols + operating in other layers. For example, local security + requirements may dictate the substitution of stronger or weaker + "reliable secure transport" layer security algorithms or + protocols. These can be introduced with no change or awareness of + the substitution by the layers above the Reliable/Secure Transport + layer. + + - The protocol used for a given layer is simpler because it is + focused on a specific narrow problem that is assigned to its + service layer. In particular, it should be feasible to leverage + existing protocol designs for some aspects of this protocol stack + (e.g. CORBA GIOP/CDR for the presentation layer). + + - A legacy AAA protocol message (e.g. a RADIUS message) can be + encapsulated within the protocol message(s) of a lower layer + protocol, preserving the investment of a Service Provider or User + Home Organization in their existing AAA infrastructure. + + - At each service layer, a suite of alternatives can be designed, + and the service layer above it can choose which alternative makes + sense for a given application. However, it should be a primary + goal of the AAA protocol standardization effort to specify one + mandatory to implement protocol at the AAA Transaction/Session + Management (AAA-TSM) service layer (see section 3.4). + + + +de Laat, et al. Experimental [Page 13] + +RFC 2903 Generic AAA Architecture August 2000 + + +3.1. Elements of a Layered Architecture + + At each layer of a layered architecture, a number of elements need to + be defined. These elements are discussed in the following sections. + +3.1.1. Service Layer Abstract Interface Primitives + + The service layer n is assumed to present a program interface through + which its adjacent service layer n+1 can access its services. The + types of abstract program service primitives and associated + parameters exchanged across the boundary between these service layers + must be specified. + +3.1.2. Service Layer Peer End Point Name Space + + Each service layer is treated as a set of cooperating processes + distributed across multiple computing systems. The service layer + must manage an end point name space that identifies these peer + processes. The conventions by which a service layer assigns a unique + end point name to each such peer process must be specified. + +3.1.3. Peer Registration, Discovery, and Location Resolution + + Along with defining an end point name space, a service layer must + also specify how its peers: + + - announce their presence and availability, + + - discover one another when they first begin operation, and + + - detect loss of connectivity or service withdrawal. + + It is also necessary to specify what mechanisms, if any, exist to + resolve a set of service layer specific search attributes into one or + more peer end point names that match the search criteria. + +3.1.4. Trust Relationships Between Peer End Points + + Once an end point has established its initial contact with another + peer, it must decide what authentication policy to adapt. It can + trust whatever authentication was done on its behalf by a lower + service layer or, through a pre-provisioning process, implicitly + trust the peer, or else go through an authentication process with its + peer. The supported mechanisms for establishing a service layer's + end point trust relationships must be specified. + + + + + + +de Laat, et al. Experimental [Page 14] + +RFC 2903 Generic AAA Architecture August 2000 + + +3.1.5. Service Layer Finite State Machine + + To the extent that a service layer's internal states are externally + visible, the layer's behavior in terms of a Finite State Machine + (FSM) should be specified. Events that can drive the FSM state + transitions may include: + + - service layer n+1 interface primitive requests + + - protocol data unit arrivals from peer service layer n end points + received through the layer n-1 access point + + - service layer n-1 interface primitives (e.g. call backs or + interrupts) + + - timer expirations + +3.1.6. Protocol Data Unit Types + + Each service layer defines a lexicon of protocol data units (PDUs) + that communicate between the layer's peer processes the information + that controls and/or monitors that service layer's distributed state + and allows the service processes of that layer to perform their + functions. Embedded in the PDUs of each layer are the PDUs of the + higher layers which depend on its services. The PDUs of each service + layer must be specified. + +3.2. AAA Application Specific Service Layer + + AAA applications have almost unlimited diversity, but imposing some + constraints and commonality is required for them to participate in + this generic AAA architectural framework. To satisfy these + constraints, participating AAA applications would derive their + application specific program logic from a standardized "Authorization + Server" abstract base object class. They would also support an + "Authorized Session" object class. An Authorization Session object + instance represents an approved authorization request that has a + long-lived allocation of services or resources. The generic AAA + architecture could be extended to include other abstract base object + classes in the future (e.g. Authorization Reservation, Authentication + Server, etc.). How to implement the derived Authorization Server + class's public methods for a given problem domain is entirely up to + the application. One technique might be to place a software + "wrapper" around an existing embedded application specific service to + adapt it to the standardized Authorization Server object paradigm. + The major Authorization Server class methods are: + + + + + +de Laat, et al. Experimental [Page 15] + +RFC 2903 Generic AAA Architecture August 2000 + + + - Publish an advertisement that describes the Authorization Server's + service attributes and its application specific service layer end + point address. Once the Authorization Server has registered, peer + processes can discover its presence or send messages addressed to + it. + + - Application Specific Authorization Decision Function (AS-ADF) + method takes a User's application specific authorization request + and returns a decision of approve, deny, or conditionally approve + with referral to another stakeholder. In the latter case, the + application may create a reservation for the requested services or + resources. This method represents the "condition" side of a + policy rule's condition/action pair. + + - Commit a service or set of resources to a previously conditionally + approved authorization decision. For those authorization requests + that have a long-term lifecycle (as opposed to being + transactions), this method mobilizes a reservation into an + Authorized Session object instance. This method represents the + "action" side of a policy rule's condition/action pair. + + - Cancel a previously conditionally approved Authorization request. + This method releases any associated reservations for services or + resources. + + - Withdraw the Authorization Server's service advertisement. + + A key motivation for structuring an AAA application as an + Authorization Server object instance is to separate the generic + authorization decision logic from the application-specific + authorization decision logic. In many cases, the application can be + divorced from the AAA problem altogether, and its AAA responsibility + can be assigned to an external rules based generic AAA Server. (The + idea is similar to that of a trust management policy server as + defined in [5].) This would facilitate a security administrator + deploying AAA policy in a central repository. The AAA policy is + applied consistently across all users of the applications, resources, + and services controlled by the AAA server. However, it is recognized + that for many problem domains, there are unique rules intrinsic to + the application. In these cases, the generic AAA Server must refer + the User's authorization request to the relevant Application Specific + Module. + +3.3. Presentation Service Layer + + The presentation service layer solves the data representation + problems that are encountered when communicating peers exchange + complex data structures or objects between their heterogeneous + + + +de Laat, et al. Experimental [Page 16] + +RFC 2903 Generic AAA Architecture August 2000 + + + computing systems. The goal is to transfer semantically equivalent + application layer data structures regardless of the local machine + architecture, operating system, compiler, or other potential inter- + system differences. + + One way to better understand the role of the presentation layer is to + evaluate an existing example. The Generic Inter-ORB Protocol (GIOP) + and its Common Data Representation (CDR) is a presentation service + layer protocol developed by the Object Management Group (OMG) + industry consortium. GIOP is one component within the Common Object + Request Broker Architecture (CORBA). Peer Object Request Brokers + (ORB) executing on heterogeneous systems use GIOP to invoke remote + CORBA object interface methods. GIOP encodes an object method's + input and output parameters in the Common Data Representation (CDR). + While there are other presentation service layer protocols in the + industry, GIOP in combination with CDR represents a mature, + comprehensive solution that exhibits many of the presentation service + layer requirements that are applicable within the AAA protocol model. + + In the context of Internet access AAA protocols, RADIUS and its + successors use the Attribute Value Pair (AVP) paradigm as the + presentation service layer encoding scheme. While such an approach + is versatile, it is also prone to becoming splintered into many ad + hoc and vendor specific dialects. There is no structure imposed or + method to negotiate the constraints on which AVPs are combined and + interpreted for a given conversation in a consistent way across AAA + protocol implementations or problem domains. At run-time, it can be + hard for the communicating peers to negotiate to a common inter- + operable set of AVPs. + + To avoid this pitfall, a primary presentation service layer + responsibility is the ability to let peers negotiate from a base + Authorization Server object class towards a commonly understood + derived Authorization Server object class that both presentation + service layer peers have implemented for their application specific + problem domain. This negotiation implies a requirement for a + globally registered and maintained presentation service layer + hierarchy of Authorization Server object class names. + +3.4. AAA Transaction/Session Management Service Layer + + The AAA Transaction/Session Management (AAA-TSM) service layer is a + distributed set of AAA Servers, which typically reside in different + administrative domains. Collectively they are responsible for the + following three services: + + + + + + +de Laat, et al. Experimental [Page 17] + +RFC 2903 Generic AAA Architecture August 2000 + + + Authentication -- Execute the procedure(s) needed to confirm the + identity of the other parties with which the AAA TSM entity has a + trust relationship. + + Authorization -- Make an authorization decision to grant or deny a + User's request for services or resources. The generic rules based + policy engine described earlier in this document executes the + authorization decision function. When the User's request is + instantaneous and transient, then its authorization approval is + treated as an ephemeral transaction. If the authorization + approval implies a sustained consumption of a service or + resources, then the request is transformed into an Authorized + Session. For the duration of the Authorized Session's lifetime: + + - its state may be queried and reported, or + + - it may be canceled before service is completed, or + + - the service being delivered may be modified to operate under + new parameters and conditions, or + + - the service may complete on its own accord. + + In each of these cases, the AAA-TSM service layer must synchronize + the Authorized Session's distributed state across all of those AAA + Servers which are implementing that specific Authorized Session. + + Accounting -- Generate any relevant accounting information regarding + the authorization decision and the associated Authorized Session + (if any) that represents the ongoing consumption of those services + or resources. + + The peer AAA servers and their AAA-TSM end points exchange AAA-TSM + messages to realize these AAA functions. A central AAA-TSM concept + is that there is a set of one or more AAA Server stakeholders who are + solicited to approve/disapprove a User request for application layer + services. The AAA-TSM service layer routes the User's request from + one stakeholder to the next, accumulating the requisite approvals + until they have all been asked to make an authorization decision. + + The AAA Servers may also do User authentication (or re- + authentication) as part of this approval process. The overall flow + of the routing from one stakeholder to another may take the form of + the "push", "pull", or "agent" authorization models developed in [2]. + However, in principle, it is feasible to have an arbitrary routing + path of an AAA-TSM authorization request among stakeholders. Once the + final approval is received, the AAA-TSM service layer commits the + requested service by notifying all of those stakeholders that require + + + +de Laat, et al. Experimental [Page 18] + +RFC 2903 Generic AAA Architecture August 2000 + + + a confirmation (i.e. turn on a pending reservation and do a + transaction commit). Alternatively, any stakeholder among those on + the consent list can veto the authorization request. In that case, + all stakeholders who previously approved the request and had asked + for a confirmation are told that the request has been denied (i.e., + cancel reservation and do a transaction rollback). + + The AAA-TSM authorization request payload must carry its own "Context + State", such that when an AAA server receives it, there is sufficient + information that it is essentially self-contained. Embedding the + Context State within the AAA-TSM message provides two benefits. + First, the message can be immediately processed with respect to the + AAA Server's local policy, and this minimizes or altogether avoids + the need for the AAA Server to exchange additional AAA-TSM messages + with its peers to complete its piece of the overall authorization + decision. The other benefit is that the AAA Server minimizes the + amount of state information resources that it commits to a user's + pending request until it is fully approved. This helps protect + against denial of service attacks. + + One can envision many possible message elements that could be part of + the Context State carried within an AAA-TSM request message: + + - AAA-TSM session identifier, a unique handle representing this + authorization request. All AAA servers who participate in a + request's approval process and its subsequent monitoring + throughout its Session lifetime refer to this handle. + + - permission lists stating which AAA Servers are allowed to modify + which parts of the message. + + - User's authorization request, encoded as a presentation layer PDU. + + - User authentication information, (e.g. an X.509 public key + certificate). + + - User credentials information, or else a pointer to where that + information can be found by an AAA server. An example of such + credentials would be an X.509 attributes certificate. + + - the list of AAA Server stakeholders who have yet to be visited to + gain full approval of the User's authorization request. Each + element in that list contains a presentation layer message + encoding how the user authorization request should be evaluated by + its application specific Authorization Decision Function (ADF). + + - the current position in the list of AAA Server stakeholders to be + visited. + + + +de Laat, et al. Experimental [Page 19] + +RFC 2903 Generic AAA Architecture August 2000 + + + - a list of those AAA servers which have already conditionally + approved the User's authorization request, but which have + predicated their approval on the request also completing its + approval from those stakeholders who have not yet seen the + request. Each element in the list has a digital signature or + comparable mechanism by which their approval can be subsequently + verified. + + - an expiration time stamp, expressed in a universally understood + time reference, which sets a lifetime limit on the AAA-TSM + message's validity. This offers some replay attack protection, + and inhibits messages from circulating indefinitely seeking the + completion of a request's approval. + + - a message payload modification audit trail, tracing which parties + introduced changes into the User's authorization request terms and + conditions. + + - an AAA-TSM message integrity check, computed across the whole + message rather than its individual elements, and signed by the + most recent AAA-TSM layer end point process to modify the AAA-TSM + message before its transmission to its AAA-TSM peer. This + function may be delegated to the underlying Reliable Secure + Transport layer connection to that destination peer. + +3.5. AAA-TSM Service Layer Program Interface Primitives + + The AAA-TSM service layer and its adjacent presentation service layer + communicate across their boundary through a set of program interface + primitives. A key design goal is to keep these primitives the same + regardless of the higher level AAA application, analogous to a + callable "plug-in". The two service layers are responsible for + coordinating their state information. This responsibility includes + all of the pending Authorization requests and the Authorization + Sessions that they are both controlling and monitoring. The initial + contact between these two layers is through an abstract object that + is called an AAA-TSM Service Access Point (SAP). A particular + service instance between these two layers is realized in an abstract + object that is called an Authorized Session. The presentation + service layer invokes AAA-TSM interface primitives against an AAA-TSM + SAP. + + The AAA-TSM service layer interface primitives can be broadly + characterized as follows: + + - Register a presentation end point address identifier and its + associated set of attributes to a service access point. + + + + +de Laat, et al. Experimental [Page 20] + +RFC 2903 Generic AAA Architecture August 2000 + + + - Send a presentation layer message to a specified destination + presentation layer peer end point address. + + - Receive a presentation layer message from another presentation + layer end point address. A receive operation may select a + specific originating presentation layer end point address from + which the message is expected, or receive a message from any + presentation layer peer. + + - The AAA-TSM service layer calls an application specific + authorization decision function, which returns a condition code + expressing an approval, denial, or partially approves with a + referral to another AAA Server. + + - AAA-TSM service layer tells the presentation layer to commit an + earlier partially approved authorization request. + + - Cancel an earlier partially approved authorization request (i.e. + rollback). + + - The presentation service layer notifies the AAA-TSM service layer + that it has terminated an in-progress Authorized Session. + + - AAA-TSM service layer notifies the presentation service layer that + another presentation service layer peer has terminated an + Authorized Session. + + - Un-register a presentation service layer end point address. + +3.6. AAA-TSM Layer End Point Name Space + + The AAA-TSM service layer end point name space is the N-tuple formed + by concatenating the following components: + + - AAA Server's Reliable/Secure Transport layer end point address + + - AAA-TSM authorization request serial number, a unique durable + unsigned integer generated by the AAA Server who first receives + the User's authorization request. + + Some AAA applications may require that each assigned AAA-TSM + transaction serial number be stored in persistent storage, and + require that it be recoverable across AAA Server system re-boots. + The serial number generation algorithm must be guaranteed unique even + if the AAA Server does a re-boot. + + + + + + +de Laat, et al. Experimental [Page 21] + +RFC 2903 Generic AAA Architecture August 2000 + + +3.7. Protocol Stack Examples + + The layering paradigm makes it possible to use the most appropriate + syntax for each application for encoding the Application Specific + Information units of that application. This encoding would take + place at the presentation layer. Similarly the application layer can + recognize the semantics specific to each application. Figure 6 + illustrates some possible AAA protocol stacks. + + +------------++------------++-----------++-----------++----------+ + | || Application|| E-Commerce|| Bandwidth || Roaming &| + | AAA || specific || Internet || Broker || mobile IP| + | Application||object class|| Open ||cross-admin|| remote | + | Service || interface || Trading || domain || access | + | Layer ||specified in|| Protocol || COPS || AVP | + | || CORBA IDL || (IOTP) || extensions|| lexicons | + +------------++------------++-----------++-----------++----------+ + | || CORBA ||Extensible || Common || DIAMETER | + |Presentation|| Generic || Markup || Open || or | + | Service || Inter-ORB || Language || Policy || RADIUS | + | Layer || Protocol || (XML) ||Specificatn||Attribute | + | || (GIOP) || || (COPS) ||Value/Pair| + +------------++------------++-----------++-----------++----------+ + | AAA-TSM Service Layer Application Program Interface (API) | + +----------------------------------------------------------------+ + | AAA Transaction/Session Management (AAA-TSM) Service Layer | + +----------------------------------------------------------------+ + | Reliable Secure Transport Layer | + +----------------------------------------------------------------+ + + Fig. 6 -- Possible AAA Protocol Stacks + +4. Security Considerations + + Security considerations for the framework on which the work described + in this memo is based are discussed in [2]. Security requirements + for authorization are listed in section 2.2 of [3]. + + This memo identifies a basic set of AAA functions that are general in + nature and common to many different AAA applications. We propose + that a standard set of security mechanisms should be defined as part + of a base AAA protocol which would include such things as public key + encryption and digital signatures that could be applied to individual + information units within an AAA message. Security with this + granularity is needed to meet the end-to-end security requirement + specified in section 2.2.7 of [3] because a single AAA message may + + + + + +de Laat, et al. Experimental [Page 22] + +RFC 2903 Generic AAA Architecture August 2000 + + + contain multiple information units each generated by AAA servers from + different administrative domains and destined to AAA servers in + different domains. + + In addition, it may be necessary to encrypt or sign an entire AAA + message on a hop-by-hop basis. This could be handled by a standard, + lower layer protocol such as IPSEC. If so, then certain auditing + requirements will have to be met so that it can be established later + that the messages relative to some specific session ID were, in fact, + protected in a particular way. Alternatively, hop-by-hop security + mechanisms may be built into the base AAA protocol itself. + +Glossary + + Application Specific Information (ASI) -- information in an AAA + protocol message that is specific to a particular application. + + Application Specific Module (ASM) -- a software module that + implements a program interface to a generic AAA server which + handles application specific functionality for an AAA protocol + message. + + Service Provider -- an organization which provides a service. + + User -- the entity seeking authorization to use a resource or a + service. + + User Home Organization (UHO) -- An organization with whom the User + has a contractual relationship which can authenticate the User and + may be able to authorize access to resources or services. + + + + + + + + + + + + + + + + + + + + + +de Laat, et al. Experimental [Page 23] + +RFC 2903 Generic AAA Architecture August 2000 + + +References + + [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP + 9, RFC 2026, October 1996. + + [2] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, + G., de Bruijn, B., de Laat, D., Holdrege, M. and D. Spence, "AAA + Authorization Framework", RFC 2904, August 2000. + + [3] Vollbrecht, J., Calhoun, P., Farrell, S., Gommans, L., Gross, + G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA + Authorization Application Examples", RFC 2905, August 2000. + + [4] Farrell, S., Vollbrecht, J., Calhoun, P., Gommans, L., Gross, + G., de Bruijn, B., de Laat, C., Holdrege, M. and D. Spence, "AAA + Authorization Requirements", RFC 2906, August 2000. + + [5] Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis, "The + KeyNote Trust-Management System Version 2", RFC 2704, September + 1999. + +Authors' Addresses + + Cees T.A.M. de Laat + Physics and Astronomy dept. + Utrecht University + Pincetonplein 5, + 3584CC Utrecht + Netherlands + + Phone: +31 30 2534585 + Phone: +31 30 2537555 + EMail: delaat@phys.uu.nl + + + George M. Gross + Lucent Technologies + 184 Liberty Corner Road, m.s. LC2N-D13 + Warren, NJ 07059 + USA + + Phone: +1 908 580 4589 + Fax: +1 908-580-4991 + EMail: gmgross@lucent.com + + + + + + + +de Laat, et al. Experimental [Page 24] + +RFC 2903 Generic AAA Architecture August 2000 + + + Leon Gommans + Enterasys Networks EMEA + Kerkplein 24 + 2841 XM Moordrecht + The Netherlands + + Phone: +31 182 379279 + email: gommans@cabletron.com + or at University of Utrecht: + l.h.m.gommans@phys.uu.nl + + + John R. Vollbrecht + Interlink Networks, Inc. + 775 Technology Drive, Suite 200 + Ann Arbor, MI 48108 + USA + + Phone: +1 734 821 1205 + Fax: +1 734 821 1235 + EMail: jrv@interlinknetworks.com + + + David W. Spence + Interlink Networks, Inc. + 775 Technology Drive, Suite 200 + Ann Arbor, MI 48108 + USA + + Phone: +1 734 821 1203 + Fax: +1 734 821 1235 + EMail: dspence@interlinknetworks.com + + + + + + + + + + + + + + + + + + + +de Laat, et al. Experimental [Page 25] + +RFC 2903 Generic AAA Architecture August 2000 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +de Laat, et al. Experimental [Page 26] + |