RFC 2903
Generic AAA Architecture
Generic AAA Architecture 🎀
Okay bestie, let's get the basics out of the way first 💅. This is RFC 2903, titled "Generic AAA Architecture," and it came out in August 2000. It's labelled Experimental, so it's a work-in-progress proposal, not a finished standard. The authors are C. de Laat from Utrecht University, G. Gross from Lucent Technologies, L. Gommans from Enterasys Networks EMEA, and J. Vollbrecht and D. Spence, both from Interlink Networks, Inc. The title block doesn't list anything this one obsoletes or updates, so it's standing on its own ✨.
Status of this Memo 📜
Real quick, this memo defines an Experimental Protocol for the Internet community 🧪. It does not specify an Internet standard of any kind. The authors are literally asking for discussion and suggestions for improvement 🙏. 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 🔐. The core idea is a generic AAA server, plus an application interface that connects it to a set of Application Specific Modules. Those modules can handle the app-specific AAA functions 🧩. Next, it proposes separating the AAA functions that a multi-domain environment needs, using a layered protocol abstraction 🍰. The long-term goal is a generic framework where complex authorizations can happen across a whole network of interconnected AAA servers 🌸.
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 ....................................... 261. Introduction 🌟
Okay so this work started out as the Authorization subgroup of the IETF's AAA Working Group 👯. Then the AAA working group's charter got refocused on MobileIP and NAS requirements, so the AAAarch Research Group got chartered inside the IRTF to keep going with the architecture work the subgroup had started 🚀. This memo is one of four that the subgroup made 📚. It's a starting point for more work in the AAAarch Research Group. It's still a work in progress, and it's published so the AAAarch subgroup and everyone else in this space can use it. It is not meant to be a final, definitive description of architecture or requirements 🙈.
The authorization subgroup already proposed an "AAA Authorization Framework" [2], which was shown off with lots of application examples [3]. Those examples led to a proposed list of authorization requirements [4] 📝. This memo builds on the framework from [2] by proposing an AAA infrastructure made of a network of cooperating generic AAA servers that talk to each other through a standard protocol 🤝. The protocol should be pretty general and support the needs of lots of different applications that need AAA functionality 💖. To get there, it will need to work in a multi-domain environment, with multiple service providers and with entities playing other AAA roles, like User Home Organizations and brokers 🌍. It should be possible to bundle requests for several authorizations of different types into one authorization transaction ✨. The AAA infrastructure will be required to forward the pieces of those requests to the right AAA servers for authorization, and then collect the authorization decisions from all the AAA servers it consulted 📬. All of this is pretty general, so it can live in the common infrastructure 🏠.
But every application that needs AAA has its own unique needs 💅. Once a service is authorized, it has to get configured and initialised ⚙️. That takes application-specific knowledge, and it might need application-specific protocols to talk to application-specific service components 🧠. To cover all of that, we propose an application interface between a generic AAA server and one or more Application Specific Modules (ASMs), which can handle the unique functionality each application needs 🎁.
Since the data each application needs for authentication, authorization, or accounting can have a unique structure, the standard AAA protocol should allow opaque units of Application Specific Information (ASI) to be encapsulated 📦. These units start with a standard header so the generic infrastructure can forward them 🧭. When an ASI unit reaches its final destination, the generic AAA server passes it across its program interface to the right ASM for application-specific processing 🎯. Even so, the design still aims to encode information units in standard ways as much as possible, so a generic rule-based engine can process them 🤖.
Section 2 explores how the generic AAA server interacts with the Application Specific Modules and with other servers to pull off complex AAA functions 🕸️. Then, in section 3, we try to organise the AAA functions into logical groups using a protocol layering abstraction 🍓. This abstraction is not meant to be a reference model that's ready for protocol design 🙅♀️. There are still lots of open questions and unsolved problems at this stage. It may turn out that something other than layering works better or, more likely, the application layer will need some substructure of its own 🧩.
Finally, in section 4, we show how the security requirements from [4] can be met in the generic server and the Application Specific Modules 🔒. The trick is applying security techniques like public key encryption or digital signatures to each ASI unit individually 🔑. That way, different stakeholders in the AAA server network can protect selected information units from being read or changed by other stakeholders in an authentication, authorization, or accounting chain 🛡️.
2. Generic AAA Architecture 🏗️
Long term, we picture a generic AAA server that can authenticate users, handle authorization requests, and collect accounting data 💫. For a service provider, that server would connect to an application-specific module that manages the resource needing authorization 🎀. Generic AAA components would also get deployed in other administrative domains to handle authorization functions 🌐.
2.1. Architectural Components of a Generic AAA Server 🧱
2.1.1. Authorization Rule Evaluation ⚖️
Step one in authorization is that the user, or something acting on the user's behalf, sends a well-formatted request to an AAA server 📨. A generic AAA server has rules (logic and/or algebraic formulas) to inspect that request and reach an authorization decision 🧮. The first problem that pops up is that Application Specific Information (ASI) has to be separated from the underlying authorization logic 😵💫. Ideally the AAA server would have a rule-based engine at that point, one that knows the logic rules and understands some generic information in the request. It wouldn't know anything about application-specific information, though, except where that information can be evaluated to a boolean or numerical value 🔢. It should be possible to write rules that refer to data elements nobody considered when the application was created 🌱.
Here's a fun example 🎮. Say you want to run a remote virtual control room experiment from home using a dialin provider. The request only succeeds if the dialin access server allows it, if there's bandwidth available (bandwidth broker), and if the experimenter has the money to pay for it (E-Commerce) 💸. The people who specified the bandwidth broker protocol probably didn't imagine combining quality of service with a network service authorization in one AAA request 🙃. But this generic model would totally 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 Request2.1.2. Application Specific Module (ASM) 🎀
okay so eventually an AAA server has to talk to an application specific module (ASM) 💅. In a service provider, the ASM manages resources and configures the service equipment so the authorized service actually happens 🔥. It might also jump into the authorization decision itself, since it has the app-specific knowledge needed 🧠. A user home organization (UHO) may need ASMs too, for application specific user authorization stuff. For example, a UHO ASM might be required to access certain application specific databases or interpret application specific service level specifications 🧚.
Whatever role an administration plays in an authorization decision, the generic AAA server's capabilities and its interface to the ASMs stay the same 🦋. That interface could be an Application Program Interface (API) or even a protocol based interface. In this model though, the ASM is treated as its own separate architectural component, apart from the generic AAA server. So 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 that happen in the AAA server ⏰. This database can be used to account for authorizations that were given, but it can also be used in rules. Imagine a rule where 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 that authorization decisions can be made about, plus the policy rules to make those decisions, is also needed 💖. Here too, the naming space for services and resources is important, since they must be addressable from other AAA servers so they can 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 components above implemented, the AAA server can handle AAA requests. It inspects the contents of the request, figures out what authorization is requested, grabs the policy rules from the repository, does various local functions, and then picks one of the following options to further process each part 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.
The next sections walk through the generic model step by step 🦋.
2.2.1. Generic AAA Server Interactions 🌸
Figure 2 shows a generic AAA server with connections to the architectural components we just covered. 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 talks to the service through a second protocol, which the figure labels as type "2". We say no more about the type 2 protocol than that it must support some global naming space for the application specific items. The same goes 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 Interactions2.2.2. Compatibility with Legacy Protocols 🕰️
Because so much equipment already runs legacy AAA protocols, and because we want the new protocol's features without throwing away existing infrastructure 🙈, it may be useful to implement an AAA gateway function. That gateway can encapsulate legacy protocol data units within messages of the new protocol. For example, this would let Radius attribute value pairs be encapsulated in Application Specific Information (ASI) units of the new protocol. Those ASI units can then be digitally signed and encrypted for end-to-end protection between a service provider's AAA server and a home AAA server, even when they talk through a marginally trusted proxy AAA server 🔒. The service provider's NAS talks Radius to the service provider's AAA server, but the AAA servers talk to each other over the new AAA protocol ✨. In this case, the AAA gateway would be a software module living in the service provider's AAA server. Or the AAA gateway could be a standalone process instead 🧚.
Figure 3 shows an AAA gateway. Communication type 4 is the legacy protocol. Communication type 1 is the future standard AAA protocol. 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 Protocols2.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 that case, the interface between them is just a software interface. But the service itself might be provided by equipment outside the ASM, like a router in the bandwidth broker application 🛜. Then the ASM talks to the service over some protocol. Figure 4 shows both possibilities. Either way, the communication between the ASM and the service is labeled 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)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 shows a network of generic AAA servers in different administrative domains talking to each other 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 Architecture2.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 🙈.
- 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
okay so the big dream 💖 is that this model could help us design an AAA protocol that's kinda "future proof" ✨. Loads of stuff we can't even think of yet can be encoded as application specific information and then referenced by policy rules sitting in a policy repository 🗂️. From this model, some generic requirements pop up that need more study 🤓. Like, say a new user gets told that somewhere on a specific AAA server they can get a certain authorization 🎀. They'll need an AAA protocol that can:
- send a query to find out which authorizations can be obtained from a specific server,
- provide a mechanism for determining what components must be put in an AAA request for a specific authorization, and
- formulate and transmit the authorization request.
Some areas that especially need work are identifying and designing the generic components of an AAA protocol 🧩, and figuring out the basis on which component forwarding and policy retrieval decisions get made 🗺️.
On top of that, we need to explore managing rules in a multi-domain AAA environment 🌍, because the development and future deployment of a generic multi-domain AAA infrastructure really depends on it being manageable 💅. Multi-domain AAA environments with tons of rules spread over several AAA servers get unmanageable FAST if there isn't some form of automated rule creation and housekeeping 😭. Organizations that let their services be governed by rules, based on some form of commercial contract, want that contract implemented with the least possible effort 💼. This can, for example, be done 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 that belong to multiple autonomous administrative domains 👑.
3. Layered AAA Protocol Model
okay, so in the last section we floated the idea of a generic AAA server with an interface to one or more Application Specific Modules (ASMs) 🧁. The generic server would handle lots of common functions, including forwarding AAA messages between servers in different administrative domains 🚚. We see message transport, hop-by-hop security, and message forwarding as clearly being functions of the generic server 🔐. The application specific modules would handle all the application specific tasks, like talking to service equipment and accessing special purpose databases 🛠️. Between these two sets of functions is another set that could presumably happen in either the generic server or an ASM, or possibly through a collaboration of both 🤝. These include evaluating authorization rules against data that may live 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 gets and the simpler the ASMs can be 💪.
One way to organize all those functions would be to assign them to a layered hierarchy 🪜. Honestly, we've found the layer paradigm really useful for understanding AAA functionality 🧠. This section explores a layered hierarchy made 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 LayerNevertheless 🙃, 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. So this paper can probably be best understood as the beginnings of work to understand and organize the common functionality required for a general purpose AAA infrastructure 🌱, rather than as a mature reference model for creating AAA protocols.
In our view of AAA services modeled as a hierarchy of service layers 🎂, there's a set of distributed processes at each service layer that cooperate and are responsible for implementing that layer's functions 🤝. These processes talk to each other using a protocol specialized to carry out the functions and responsibilities assigned to their service layer 💬. The protocol at service layer n talks to its peers by depending on the services available to it from service layer n-1 🪄. 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 here is that there isn't just one monolithic "AAA protocol" 🙅♀️. Instead there's a whole 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's focused on one specific narrow problem 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) 👑.
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's 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 📜.
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 ✨
okay so AAA applications are literally wildly diverse 💅, but they still need some shared rules so they can join this generic AAA framework together 🫶. To make that happen, every participating AAA application derives its app-specific logic from a standardized "Authorization Server" abstract base object class 🎀. They also support an "Authorized Session" object class 🦋. An Authorization Session object instance is basically an approved request that holds a long-lived allocation of services or resources 💜. The generic AAA architecture could grow to include other abstract base object classes later on (for example Authorization Reservation or Authentication Server 🌸). How the derived Authorization Server class's public methods get implemented for a given problem domain is totally up to the application 🔥. One technique is to slap a software "wrapper" around an existing embedded application-specific service so it fits the standardized Authorization Server object paradigm 🧚. The major Authorization Server class methods are:
- 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 📣.
- The 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 lots of cases, the application can be totally divorced from the AAA problem, and its AAA responsibility can be handed off 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 makes life way easier for a security administrator who wants to deploy AAA policy from a central repository 🎀. The AAA policy gets applied consistently across all users of the applications, resources, and services controlled by the AAA server 🫧. However, it's recognized that for many problem domains there are unique rules intrinsic to the application 🦄. In those 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 come up when communicating peers exchange complex data structures or objects between their heterogeneous computing systems 💻. The goal is to transfer semantically equivalent application layer data structures no matter the local machine architecture, operating system, compiler, or other potential inter-system differences ✨.
One way to really get the role of the presentation layer is to check out 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) running 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) 💜. There are other presentation service layer protocols out there too, but GIOP combined with CDR is a mature, comprehensive solution that shows off many of the presentation service layer requirements that apply 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 that approach is super versatile, it's also prone to splintering into a bunch of ad hoc and vendor specific dialects 😭. There's no structure imposed and no method to negotiate the constraints on which AVPs get combined and interpreted for a given conversation, consistently across AAA protocol implementations or problem domains 💀. At run-time, it can be hard for communicating peers to negotiate their way to a common interoperable set of AVPs 🙈.
To dodge this pitfall, a primary presentation service layer responsibility is letting peers negotiate from a base Authorization Server object class toward 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 🦋
okay so the AAA Transaction/Session Management (AAA-TSM) service layer is a distributed group of AAA Servers, and they usually live in different administrative domains 🌍. Together they handle three jobs. bestie, these three are the whole point 💖
- Authentication: they run whatever procedure(s) are needed to confirm who the other parties are, as long as the AAA TSM entity has a trust relationship with them 🔐
- Authorization: they decide whether to grant or deny a User's request for services or resources ✅. The generic rules-based policy engine from earlier in this document is what actually runs the authorization decision function. Here's the tea:
- if the User's request is instantaneous and transient, the approval is treated as an ephemeral transaction ⚡
- if the approval means a sustained consumption of a service or resources, the request gets transformed into an Authorized Session 🎀. While that Authorized Session is alive:
- its state can be queried and reported, or
- it can be canceled before the service is completed, or
- the service being delivered can be modified to run under new parameters and conditions, or
- the service can complete on its own accord.
In each of these cases, the AAA-TSM service layer has to synchronize the Authorized Session's distributed state across every AAA Server that's implementing that specific Authorized Session 🫶
- Accounting: they generate any relevant accounting information about the authorization decision and the associated Authorized Session (if there is one) that tracks the ongoing consumption of those services or resources 📊
The peer AAA servers and their AAA-TSM end points swap AAA-TSM messages to make these AAA functions happen 💌. The central idea here is that there's a set of one or more AAA Server stakeholders who get asked to approve or disapprove a User's request for application layer services. The AAA-TSM service layer passes the User's request from one stakeholder to the next, collecting approvals along the way, until they've all been asked to make an authorization decision 🔁.
The AAA Servers can also do User authentication (or re-authentication) as part of this approval process 🔑. The overall routing from one stakeholder to another might look like the "push", "pull", or "agent" authorization models developed in [2]. But in principle, an AAA-TSM authorization request can take any routing path among stakeholders, so it's pretty flexible 🧚. Once the final approval comes in, the AAA-TSM service layer commits the requested service by notifying every stakeholder that needs a confirmation. That means turning on a pending reservation and doing a transaction commit ✨. On the flip side, any stakeholder on the consent list can veto the authorization request 🙅♀️. If that happens, everyone who already approved the request and asked for a confirmation gets told it's been denied. That means canceling the reservation and doing a transaction rollback 💀.
The AAA-TSM authorization request payload has to carry its own "Context State", so that when an AAA Server receives it, there's enough info for it to be basically self-contained 📦. Putting the Context State inside the AAA-TSM message gives two big wins. First, the message can be processed right away against the AAA Server's local policy, which minimizes or completely avoids the need for that server to swap extra AAA-TSM messages with its peers just to finish its part of the overall authorization decision 🏃♀️. Second, the AAA Server doesn't have to commit a ton of state resources to a user's pending request until it's fully approved. That helps protect against denial of service attacks 🛡️.
Here are the message elements you could imagine being part of the Context State carried in an AAA-TSM request message 🍓:
- AAA-TSM session identifier, a unique handle representing this authorization request. Every AAA server that takes part in the request's approval process, and in its monitoring for the whole Session lifetime, refers 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 an AAA server can find that information. An example of such credentials would be an X.509 attributes certificate 🗝️.
- the list of AAA Server stakeholders who still need 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 📍.
- a list of those AAA servers which have already conditionally approved the User's authorization request, but which made their approval depend on the request also completing its approval from those stakeholders who haven't seen it yet. Each element in the list has a digital signature or comparable mechanism so its approval can be verified later ✍️.
- 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 stops messages from circulating forever while they hunt for a request's approval ⏳.
- a message payload modification audit trail, tracing which parties made changes to 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 that modified the AAA-TSM message before it was sent 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 the presentation service layer right next to it talk across their boundary through a set of program interface primitives 🤝. A key design goal is to keep these primitives the same no matter which higher level AAA application is running, kind of like a callable "plug-in" 🎀. The two service layers are responsible for keeping their state info in sync 🧠. That covers all the pending Authorization requests and the Authorization Sessions that they're both controlling and monitoring. The very first contact between these two layers happens through an abstract object called an AAA-TSM Service Access Point (SAP) 🚪. A particular service instance between these two layers is realized in an abstract object called an Authorized Session 🦋. The presentation service layer invokes AAA-TSM interface primitives against an AAA-TSM SAP 💅.
Broadly speaking, the AAA-TSM service layer interface primitives look like this:
- Register a presentation end point address identifier and its associated set of attributes to a service access point 📥.
- 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 can select a specific originating presentation layer end point address that the message is expected from, 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, a denial, or a partial approval with a referral to another AAA Server 🚦.
- The 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 🛑.
- The 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 an N-tuple, formed by concatenating these 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 that first receives the User's authorization request 🔢.
Some AAA applications may need each assigned AAA-TSM transaction serial number stored in persistent storage, and need it to be recoverable across AAA Server system re-boots 💾. The serial number generation algorithm has to be guaranteed unique even if the AAA Server does a re-boot 🔥.
3.7. Protocol Stack Examples 🥞
The layering paradigm makes it possible to use the most appropriate syntax for each application when encoding the Application Specific Information units of that application ✨. That encoding happens at the presentation layer. In the same way, the application layer can recognize the semantics specific to each application 🧚♀️. Figure 6 shows 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 Stacks4. Security Considerations ✨
okay bestie, this section is SERIOUS but also kinda iconic, so let's get into it 🔐💅
Security considerations for the framework this work is built on get discussed in [2]. The security requirements for authorization are listed in section 2.2 of [3]. 🫶
This memo pins down a basic set of AAA functions that are general and shared by lots of different AAA applications. 🌸 The vibe here is that a standard set of security mechanisms should be defined as part of a base AAA protocol. Those would include stuff like public key encryption and digital signatures that could be applied to individual information units inside an AAA message. 🔥 This level of granularity is needed to meet the end-to-end security requirement from section 2.2.7 of [3], and here's why it matters: a single AAA message can contain multiple information units, each generated by AAA servers from different administrative domains and each destined for AAA servers in different domains. Main character energy for sure, but it also means the protection has to be per unit 😭
Heads up: the security needs to be applied to each individual information unit, not just the message as a whole, or the end-to-end requirement doesn't get met. 💀
Also, 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 that happens, 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 📖
okay, the glossary is where the vocab lives, so let's go 💜
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, and it 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. It can authenticate the User and may be able to authorize access to resources or services. 👑
References 📚
okay, the references are the receipts, so here they are 🧾
[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 📮
okay the authors, the people behind the magic ✨
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
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
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. 🧚
📦 where this page comes from
- ietf: rfc2903 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms