RFC 2905
AAA Authorization Application Examples
RFC 2905: AAA Authorization Application Examples 🎀
Okay bestie, this RFC looks at real Internet apps that need authorization, and it's giving very "how do we even do this" energy ✨ Here's the title block tea:
- Authors: J. Vollbrecht (Interlink Networks, Inc.), P. Calhoun (Sun Microsystems, Inc.), S. Farrell (Baltimore Technologies), L. Gommans (Enterasys Networks EMEA), G. Gross (Lucent Technologies), B. de Bruijn (Interpay Nederland B.V.), C. de Laat (Utrecht University), M. Holdrege (ipVerse), and D. Spence (Interlink Networks, Inc.) 💅
- Category: Informational 🌸, so it's sharing info, not a standard
- Date: August 2000 🗓️
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
- Series: it's Request for Comments 2905, from the Network Working Group 💜
Status of this Memo 📜
This memo is an info drop for the Internet community 💖 It does not specify an Internet standard of any kind, so don't treat it like one 🙅 Distribution is unlimited, so share away 🦋
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🌈
Abstract ✨
So the vibe here is that this memo walks through several apps that need authorization, and each one gets the same framework so they're easy to compare 💅 The specific authorization requirements of each app are spelled out. Heads up though: this material wasn't contributed by the working groups responsible for those apps, so it should not be considered prescriptive for how they'll meet their authorization needs 🙈 The real goal is to explore what a bunch of different apps fundamentally need, with the aim of compiling a set of requirements an authorization protocol will need to meet to be generally useful 🔥
Table of Contents 🗂️
1. Introduction ................................................ 3
2. PPP Dialin with Roaming ..................................... 4
2.1. Descriptive Model ...................................... 4
2.2. Authorization Requirements ............................. 6
3. Mobile-IP ................................................... 6
3.1. Relationship to the Framework .......................... 10
3.2. Minimized Internet Traversal ........................... 10
3.3. Key Distribution ....................................... 10
3.4. Mobile-IP Authorization Requirements ................... 11
4. Bandwidth Broker ............................................ 12
4.1. Model Description ...................................... 13
4.2. Components of the Two-Tier Model ....................... 13
4.3. Identification of Contractual Relationships ............ 13
4.3.1. Single-Domain Case .............................. 14
4.3.2. Multi-Domain Case ............................... 15
4.4. Identification of Trust Relationships .................. 16
4.5. Communication Models and Trust Relationships ........... 18
4.6. Bandwidth Broker Communication Models .................. 19
4.6.1. Concepts ........................................ 19
4.6.1.1. Intra-Domain Authorization ............... 19
4.6.1.2. Inter-Domain Authorization ............... 19
4.6.2. Bandwidth Broker Work Phases .................... 20
4.6.3. Inter-Domain Signaling .......................... 20
4.6.3.1. Phase 0 .................................. 20
4.6.3.2. Phase 1 .................................. 20
4.6.4. Bandwidth Broker Communication Architecture ..... 22
4.6.5. Two-Tier Inter-Domain Model ..................... 23
4.6.5.1. Session Initialization ................... 23
4.6.5.2. Service Setup ............................ 23
4.6.5.3. Service Cancellation ..................... 24
4.6.5.4. Service Renegotiation .................... 24
4.6.5.5. RAR and RAA .............................. 24
4.6.5.6. Session Maintenance ...................... 24
4.6.5.7. Intra-domain Interface Protocol .......... 24
4.7. Requirements ........................................... 24
5. Internet Printing ........................................... 25
5.1. Trust Relationships .................................... 26
5.2. Use of Attribute Certificates .......................... 27
5.3. IPP and the Authorization Descriptive Model ............ 28
6. Electronic Commerce ......................................... 29
6.1. Model Description ...................................... 30
6.1.1. Identification of Components .................... 30
6.1.2. Identification of Contractual Relationships ..... 31
6.1.3. Identification of Trust Relationships ........... 32
6.1.3.1. Static Trust Relationships ............... 33
6.1.3.2. Dynamic Trust Relationships .............. 35
6.1.4. Communication Model ............................. 35
6.2. Multi Domain Model ..................................... 37
6.3. Requirements ........................................... 38
7. Computer Based Education and Distance Learning .............. 40
7.1. Model Description ...................................... 40
7.1.1. Identification of Components .................... 40
7.1.2. Identification of Contractual Relationships ..... 41
7.1.3. Identification of Trust Relationships ........... 43
7.1.4. Sequence of Requests ............................ 44
7.2. Requirements ........................................... 46
8. Security Considerations ..................................... 47
Glossary ....................................................... 47
References ..................................................... 48
Authors' Addresses ............................................. 50
Full Copyright Statement ....................................... 531. Introduction ✨
This doc is one of a series of three that the AAAarch RG is looking at, all about the authorization requirements for AAA protocols 📚 The three are:
AAA Authorization Framework [2]
AAA Authorization Requirements [3]
AAA Authorization Application Examples (this document)In here, we check out several important Internet apps that require authorization 🔍 For each app, we present a model showing how it might do authorization, then map that model back to the framework presented in [2]. After that, we go through the app's authorization requirements as well as we presently understand them. The requirements in this memo have been collected together, generalized, and presented in [3] 💜
The intent of this memo is to validate and illustrate the framework in [2] and to motivate the requirements in [3]. This work is meant to be in alignment with the work of the various working groups responsible for the authorization apps illustrated. Still, this memo should not be regarded as authoritative for any of the apps illustrated. Where authoritative documents exist or are in development, they're listed in the references at the end of this document 🫶
This memo has a bit of a glow-up story 🦋 The work 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. It's a starting point for further work within the AAAarch Research Group, and it's still a work in progress 🌸 It's published so the work is available for the AAAarch subgroup and others working in this area, not as a definitive description of architecture or requirements.
Quick terms check 🤓 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4].
2. PPP Dialin with Roaming 📞
In this section, we present an authorization model for dialin network access in terms of the framework presented in [2]. The model includes the multi-domain considerations required for roaming [5]. Detailed requirements for network access protocols are presented in [6] 👑
Part 1 of 12. More parts are coming, so don't go anywhere 💜
2.1. Descriptive Model ✨
okay so this is where the RFC gets into the vibe check of how dialin roaming actually works 🫶 The PPP dialin app uses the pull sequence (see [2]), and the roaming case uses the roaming pull sequence, also from [2]. They redrew it with dialin roaming terminology in figure 1, and bestie, it is a whole mood 🌈
+------+ +-------------------------+
| | | Home ISP |
| | | (User Home Organization)|
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | +--------------+---+------+
| | | |
| | |3 |4
| | | |
| | +--------------+---+------+
| | | Visited ISP | | |
| | | | \|/ |
| User | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | /|\ | |
| | | |2 |5 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| NAS (Service | |
| |<-----+--| Equipment) | |
| | 6 | +-------------------+ |
| | | (Service Provider) |
+------+ PPP +-------------------------+
Fig. 1 -- Dialin Authorization
Based on Roaming Pull SequenceSo the User dials in to a Network Access Server (NAS) run by the visited (or foreign) ISP, which is the Service Provider in the general model 💖 The User gets authenticated with a protocol like PAP, CHAP, or EAP, all wrapped up in PPP frames (1). Here's the tea: the User doesn't have network access yet, so they literally can't send IP datagrams to a AAA server 😭 The only one they can talk to is the NAS (Service Equipment).
The NAS then forwards the User's authentication/authorization request, including the Network Access Identifier (NAI) [7], to a AAA server in its own domain using RADIUS [8] or a successor AAA protocol (2). The visited ISP's AAA server checks the realm from the NAI and passes the request along to the User's home domain AAA server (3). That home server authenticates the user and authorizes access according to a roaming agreement 👑 It may send service parameters (e.g. Idle-Timeout) back to the visited ISP's AAA server (4), which forwards them to the NAS, possibly adding extra service parameters of its own (5). And finally, the NAS completes PPP session initialization (6). Main character energy, no cap ✨
The RFC also says this model may get expanded in a few ways in the future [9] 🦋 For example, Authentication and Authorization could happen in separate passes using different servers, to support specialized forms of authentication. Or, to make roaming better, a broker could be slotted in between the visited ISP and the home ISP. Or authorization could be based on other identifiers, like the caller ID and called ID from the PSTN (e.g., using ANI and DNIS) 🎀
2.2. Authorization Requirements 💅
The requirements for authorizing PPP dialin service using roaming are listed in [9], and iykyk, these are the rules the AAA protocol has to follow 🔥
- Authorization separate from authentication should be allowed when necessary, but the AAA protocol MUST allow for a single message to request both authentication and authorization.
- The AAA protocol MUST be "proxyable", meaning that a AAA Server or PDP MUST be able to forward the request to another AAA Server or PDP, which may or may not be within the same administrative domain.
- The AAA protocol MUST allow for intermediate brokers to add their own local Authorization information to a request or response.
- When a broker is involved, the protocol MUST provide end to end security.
- The broker MUST be able to return a forwarding address to a requester, allowing two nodes to communicate together.
- The protocol MUST provide the following features (per user session):
- One Authentication, One Authorization
- One Authentication, Multiple Authorization
- Multiple Authentication, Multiple Authorization
3. Mobile-IP ✨
okay so Mobile-IP is the protocol that lets an IP host move between IP subnets and still be reachable 🧚💖 it's giving "I'm everywhere but still me." Recent work in the Mobile-IP Working Group added AAA into the mix, and the goals are:
- Better scaling of security associations 🔐
- Mobility across administrative domain boundaries 🗺️
- Dynamic assignment of Home Agent 🏠
ngl, Mobile IP as defined in [10] is solid when every mobile node lives in the same administrative domain 🫶 but the group is now trying to make it scale across domains, and that changes the trust model [10] sets up. The requirements for Mobile-IP authorization are written up in [11]. In this section we build a multi-domain model for Mobile-IP authorization and describe it using the framework from [2]. main character energy 👑
Figure 2 shows the new AAA trust model for Mobile-IP. Every network has mobile nodes (MN) and an AAA server (AAA). Each mobility device shares a security association (SA) with the AAA server in its own home network, so none of the mobility devices start out sharing a security association with each other 🙈 The AAA servers of the two administrative domains can either share a security association with each other, or each have one with an intermediate broker.
Broker AAA
+--------+
| |
| AAA |
/=====| |=====\
// +--------+ \\
Foreign // SA SA \\ Home
AAA // \\ AAA
+--------+ +--------+
| | SA | |
| AAA |======================| AAA |
| | (in lieu of broker) | |
+--------+ +--------+
|| || ||
SA || SA || || SA
|| || ||
|| || ||
+---------+ +---------+ +---------+
| | | | | |
| FA | | HA | | MN |
| | | | | |
+---------+ +---------+ +---------+
Fig. 2 -- Mobile-IP AAA Trust ModelFigure 3 gives an example of a Mobile-IP network with AAA in it 💅 In this integrated Mobile-IP/AAA network, each mobility agent shares a security association with its local AAA server. The Home and Foreign AAA servers both share a security association with the broker's AAA server. Lastly, each mobile node has a trust relationship with its home AAA server 🎀
Visited Access Broker Home IP
Provider Network Network Network
+--------+ +--------+ +--------+
| | | | | |
| AAA |------| AAA |------| AAA |
| | | | | |
+--------+ +--------+ +--------+
| |
| |
AAA | | AAA
| |
| |
+---------+ +---------+
| | | |
| FA | | HA |
| | | |
+---------+ +---------+
|
| Visited Access Home Network
| Provider Network -Private Network
Mobile | -Home Provider
IP | -Home ISP
|
+--------+
| Mobile |
| Node |
+--------+
Fig. 3 -- General Wireless IP Architecture for Mobile-IP AAAHere's how it plays out 🦋 a Mobile Node shows up in a foreign network and sends a registration to the Foreign Agent. The Foreign Agent doesn't share a security association with the Home Agent, so it sends an AAA request to its local AAA server. That request carries the authentication information and the Mobile-IP registration request. The Mobile Node can't talk straight to the home AAA server, and there are two reasons:
- It doesn't have access to the network yet. The registration request is how it asks for access in the first place.
- It might not have an IP address, and it may want its home provider to assign one.
The Foreign AAA server works out whether it can handle the request locally, using the Network Access Identifier [7] the Mobile Node gave it. The NAI looks like user@realm, and the AAA server uses the realm part to find the Mobile Node's home AAA server 🔍 If the Foreign AAA server has no security association with that home AAA server, it may forward the request to its broker. If the broker has a relationship with the home network, it can pass the request along. Otherwise, a failed response goes back to the Foreign AAA server 😭
When the home AAA server gets the AAA Request, it authenticates the user and starts the authorization phase. Authorization includes generating:
- Dynamic Session Keys to be distributed among all Mobility Agents 🔑
- Optional Dynamic assignment of a Home Agent
- Optional Dynamic assignment of a Home Address (note this could be done by the Home Agent).
- Optional Assignment of QOS parameters for the Mobile Node [12]
Once authorization is done, the home AAA server sends an unsolicited AAA request to the Home Agent. It includes everything from the original AAA request plus the authorization information the home AAA server generated. The Home Agent pulls the Registration Request out of the AAA request and processes it, then makes a Registration Reply and sends it back to the home AAA server in an AAA response. That message goes through the broker, back to the Foreign AAA server, and finally lands at the Foreign Agent 🧚✨
The AAA servers keep session state based on the authorization information. If a Mobile Node moves to another Foreign Agent inside the same foreign domain, a request to the foreign AAA server can go out right away to get back the keys that were issued to the previous Foreign Agent. That cuts out an extra round trip across the internet when micro mobility is involved, and it makes hand-off smooth 🌈 iconic.
3.1. Relationship to the Framework
Mobile-IP uses the roaming pull model described in [2]. The Mobile Node is the User. The Foreign Network is the Service Provider, with the Foreign Agent as the Service Equipment. The Home Network is the User Home Organization. Note that the User Home Organization runs not just an AAA Server but also the Home Agent 🏠 Also, a broker sits between the Service Provider and the User Home Organization 🤝
3.2. Minimized Internet Traversal
It would have been possible to do the AAA interactions for basic authentication and authorization, and send the Registration flow straight from the Foreign Agent to the Home Agent. But one of the big Mobile-IP AAA requirements is to minimize Internet Traversals 💖 Putting the Registration Request and Replies inside the AAA messages means one traversal handles authentication, authorization, and processing of the Registration Request all at once. This streamlined approach is required so that wireless (cellular) devices get network access with less latency ⚡ New registrations should not increase connect time beyond what current cellular networks provide.
3.3. Key Distribution
To scale wireless data access across administrative domains, the number of security associations has to be kept small 🌸 So each Foreign Agent does not share a security association with every Home Agent on the Internet. The Mobility Agents share a security association with their local AAA server, and those AAA servers share security associations with each other. Brokers, as defined by the Roaming Operations (roamops) Working Group, help here too, because they let providers cut down on the number of relationships they need to set up 🦋
After a Mobile Node is authenticated, the authorization phase generates Sessions Keys. Specifically, three keys are generated:
- k1 - Key to be shared between the Mobile Node and the Home Agent 🔑
- k2 - Key to be shared between the Mobile Node and the Foreign Agent 🔑
- k3 - Key to be shared between the Foreign Agent and the Home Agent 🔑
Each key gets propagated to each mobility device. The Foreign and Home Agents get theirs through the AAA protocol, and the Mobile Node gets its key via Mobile-IP, since the Mobile Node doesn't talk to the AAA servers directly 💜
Figure 4 shows the new security associations used for Mobile-IP message integrity, using the keys the AAA server derived 🎀
+--------+ +--------+
| | k3 | |
| FA |======================| HA |
| | | |
+--------+ +--------+
\\ //
\\ k2 k1 //
\\ +--------+ //
\\ | | //
\=====| MN |=====/
| |
+--------+
Fig. 4 -- Security Association after Key DistributionOnce the session keys are set up and propagated, the mobility devices can swap registration info directly, no AAA infrastructure needed 🫶 But session keys have a lifetime. After that, the AAA infrastructure must be used to get new session keys 💀
3.4. Mobile-IP Authorization Requirements ✨
okay so here's the recap 💅 Mobile-IP has these authorization requirements:
- Mobile-IP requires an AAA protocol that makes use of the pull model. 🫶
- Mobile-IP requires broker support, and data objects must contain data integrity and confidentiality end-to-end. This means that neither the broker nor any other intermediate AAA node should be able to decrypt the data objects, but they must be able to verify the objects' validity. 🔐
- Authorization includes Resource Management. This allows the AAA servers to maintain a snapshot of a mobile node's current location, keying information, etc. 📍
- Due to the nature of the service being offered, it is imperative that the AAA transaction add minimal latency to the connect time. Ideally, the AAA protocol should allow for a single round trip for authentication and authorization. ⏱️✨
- If the AAA protocol allows for the Mobile-IP registration messages to be embedded within the authentication/authorization request, this will further reduce the number of round trips required and hence reduce the connect time. 🔥
- It must be possible to pass Mobile-IP specific key management data along with the authorization data. This allows the AAA server to act as a Key Distribution Center (KDC). 🔑👑
- It must be possible to pass other application-specific data units such as home agent selection and home address assignment to be carried along with the authorization data units. 🎀
- The authorization response should allow for diffserv (QOS) profiles, which can be used by the mobility agents to provide some quality of service to the mobile node. 💖
- The AAA protocol must allow for unsolicited messages to be sent to a "client", such as the AAA client running on the Home Agent. 📨
4. Bandwidth Broker 🌸
this section is all about the authorization side of the Bandwidth Broker architecture, as discussed within the Internet2 Qbone BB Advisory Council. we use authorization model concepts to figure out contract relationships and trust relationships, and then we look at possible message exchanges. from that architectural model we'll pull out a set of authorization requirements for Bandwidth Brokers. the Internet 2 Qbone BB Advisory Council is researching a single and multi-domain implementation based on 2-tier authorization concepts. a 3-tier model is considered future work, so it's not part of this description. if you want the Internet 2 Bandwidth Broker work and its concepts, check out:
http://www.merit.edu/working.groups/i2-qbone-bb
the material in this section is based on [13], which is a work in progress of the Internet2 Qbone BB Advisory Council. 🦋
4.1. Model Description 🧩
building a model involves four steps:
- identification of the components that are involved and what they are called in this specific environment,
- identification of the relationships between the involved parties that are based on some form of agreement,
- identification of the relationships that are based on trust, and
- consideration of the sequence of messages exchanged between components.
4.2. Components of the Two-Tier Model for Bandwidth Brokerage 💜
we'll look at the components of a bandwidth broker transaction in the context of the conceptual entities defined in [2]. the bandwidth broker two-tier model has a User and the Service Provider controlling the Service Equipment.
here are the components:
- The Service User (User) -- a person or process that wants a certain level of QoS by requesting the allocation of a quantifiable amount of resource between a selected destination and itself. in bandwidth broker terms, the User is called a Service User, and it's capable of generating a Resource Allocation Request (RAR). 🙋♀️
- The Bandwidth Broker (Service Provider) -- a function that authorizes allocation of a specified amount of bandwidth resource between an identified source and destination based on a set of policies. in this context we call this function the Bandwidth Broker. a Bandwidth Broker is capable of managing the resource availability within a network domain it controls. 🌐
Note: a 3-tier model involving a User Home Organization is recognized in [13], but its development is left for future study, so it isn't discussed in this document. 👀
4.3. Identification of Contractual Relationships 📜
authorizations to obtain bandwidth are based on contractual relationships. in both the single and multi-domain cases, the current Bandwidth Broker model assumes that a User always has a contractual relationship with the service domain it's connected to. 💅
4.3.1. Single-Domain Case 🍓
in the single-domain case, the User has a contract with a single Service Provider in a single service domain.
+-------------+
| |
| +---------+ |
| |Bandwidth| |
+-------+ | |Broker | |
| | | | | |
|Service| | +---------+ |
|User |=========| |
| | | +---------+ |
| | | | Network | |
+-------+ | | Routing | |
| | Devices | |
| +---------+ |
| Autonomous |
| Service |
| Domain |
+-------------+
==== contractual
relationship
Fig. 5 -- Two-Tier Single Domain Contractual Relationships4.3.2. Multi-Domain Case 🌈
in the multi-domain case, the User has a contract with a single Service Provider. that Service Provider has a contract with neighboring Service Providers. this model is used when independent autonomous networks establish contracts with each other. 🦋
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +---------+ | | +---------+ |
|User |=========| |========| |
| | | +---------+ | | +---------+ |
| | | | Network | | | | Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual
relationship
Fig. 6 -- Two-Tier Multi-Domain Contractual Relationships4.4. Identification of Trust Relationships ✨
Okay so contractual relationships are kinda their own thing 💅 and they don't have to match how trust gets set up. Trust is what makes authenticated (and possibly secure) communication work 🔐 The Bandwidth Broker world has a few ways to build trusted relationships, and Figures 7 and 8 show two options for the two-tier Bandwidth Broker model 🦋
+-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| O***********O O************O | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----0----+ | | +----O----+ |
| | | |Network | | | |Network | |
+-------+ | |Routing | | | |Routing | |
| |Devices | | | |Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
Fig. 7 -- Two-Tier Multi-Domain Trust Relationships, alt 1 +-------------+ +-------------+
| | | |
| +---------+ | | +---------+ |
| |Bandwidth| | | |Bandwidth| |
+-------+ | |Broker | | | |Broker | |
| | | | | | | | | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----O----+ | | +----O----+ |
| O***********O Network O************O Network | |
+-------+ | | Routing | | | | Routing | |
| | Devices | | | | Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
Fig. 8 -- Two-Tier Multi-Domain Trust Relationships, alt 2Ngl [13] doesn't give specifics on this one 🙈 but it does admit that trust relationships are needed 💖 In the first model, a trust relationship is built on some form of authentication method, and it sits between the User and the Bandwidth Broker and also among the Bandwidth Brokers 🫶 The second model is the one that's kinda popular in enterprise networks 🏢 Here the trust relationship may come from the wiring closet, plus knowing which physical router port or MAC address is hooked up to which user 🔌 The router-Bandwidth Broker relationship may be set up physically, or through some other authentication method or secure channel.
A Certificate Authority (CA) based trust relationship is shown in figure 9 📜 The CA signs public key certificates, and those can then be used in encrypted message exchanges with public keys that everyone involved trusts 🔑 First off, each involved party has to register with the CA so it can join a trust domain. The Router-Bandwidth Broker relationship may be set up the way the two previous figures describe. The interesting part 👀 is that the bandwidth broker in domain B may route information to the user through the bandwidth broker in domain A, and BB1 can't read that information (because of end-to-end security) 🤯 This model creates a meshed trust relationship through a tree-like CA structure 🌳
+-------------------+
| Certificate |
....................| Authority |
: ..| |..
: : +-------------------+ :
: : :
: : :
: ***************:*********************** :
: * +---:---------+ +---*--:------+
: * | : | | * : |
: * | +-:-------+ | | +-O--:----+ |
: * | |{C} | | | | {C} | |
+---:--O+ | |Bandwidth| | | |Bandwidth| |
| {C} O***********O Broker O************O Broker | |
|Service| | +----O----+ | | +----O----+ |
|User |=========| * |========| * |
| | | +----0----+ | | +----O----+ |
| | | |Network | | | |Network | |
+-------+ | |Routing | | | |Routing | |
| |Devices | | | |Devices | |
| +---------+ | | +---------+ |
| Autonomous | | Autonomous |
| Service | | Service |
| Domain A | | Domain B |
+-------------+ +-------------+
==== contractual relationship
O**O trust relationship
{C}. certification process
Fig. 9 -- Two-Tier Multi-Domain Trust Relationships, alt 34.5. Communication Models and Trust Relationships 🤝
When you're describing the Bandwidth Broker communication model, you have to remember that trust relationships between components must make sure communication between the involved components is secure and authenticated 🔒 The Internet 2 Qbone Bandwidth Broker work doesn't recommend any one trust relationship model, so we make the same assumptions as [13] 📚 In theory the trust model and the communication model can be independent, but communication efficiency is what decides the most logical approach ⭐
4.6. Bandwidth Broker Communication Models 📡
4.6.1. Concepts 💭
The current Internet 2 Qbone Bandwidth Broker discussion describes a two-tier model 🎀 In it, a Bandwidth Broker accepts Resource Allocation Requests (RAR's) from users in its own domain, and also RAR's generated by upstream Bandwidth Brokers from adjacent domains. Each Bandwidth Broker manages one service domain, and it provides authorization based on a policy that decides whether a request can be honored 👑
4.6.1.1. Intra-Domain Authorization 🏠
Admission Authorization, or Connection Admission Control (CAC), for intra-domain communication is done with whatever method fits for checking resource availability inside the domain. Generally, a Bandwidth Broker configures its service domain to certain levels of service ⚙️ RAR's are then accommodated using a policy-based decision 🧠
4.6.1.2. Inter-Domain Authorization 🌐
Service Level Specifications (SLS's) are the basis for handling inter-domain bandwidth authorization requests 📝 A Bandwidth Broker keeps an eye on both the state of its network components and the state of its connections to neighboring networks 👀 SLS's are translations of SLA's that have been established between Autonomous Service Domains. Each Bandwidth Broker initializes itself so it knows about existing SLS's. SLS's are established in a unidirectional sense, so two SLS's must govern a bi-directional connection ↔️ SLS's are set up at the level of aggregate data-flows and the resources (bandwidth) provisioned for those flows 🌊
A Bandwidth Broker may honor an inter-domain RAR by applying policy decisions that figure out whether a particular RAR fits into a pre-established SLS ✅ If that works, the Bandwidth Broker authorizes the usage of the bandwidth. If it doesn't, the Bandwidth Broker may deny the request, or approve it after renegotiating the SLS with its downstream Bandwidth Broker 🤞
A separate Policy Manager may be involved in the CAC decision 🧩 The Internet 2 Qbone Bandwidth Broker discussion pictures an ideal setup where Bandwidth Brokers and Policy Managers team up to provide CAC using integrated policy services [13] 💜
4.6.2. Bandwidth Broker Work Phases 🗓️
The Internet 2 Qbone Bandwidth Broker discussion proposes building out the Bandwidth Broker model in several phases:
- Phase 0: Local Admission. RAR's are only handled within a local domain. SLS's are pre-established using manual methods (fax, e-mail).
- Phase 1: Informed Admission. RAR's spanning multiple domains are authorized based on information obtained from one or more Bandwidth Brokers along the path.
- Phase 2: Dynamic SLS admission. Bandwidth Brokers can dynamically set up new SLS's.
Even though the local admission case is covered, the current Internet 2 Qbone Bandwidth Broker work is focused on solving multi-domain problems, so individual Bandwidth Brokers can inter-operate as identified in phase 0 or 1 🌸
4.6.3. Inter-Domain Signaling 📶
4.6.3.1. Phase 0 🐣
In phase 0 implementations, there is no electronic signaling between Bandwidth Brokers, and network operators negotiate SLS's manually (phone, email etc) 📞 An RAR is only handled within the domain, and it may come from a User or an ingress router 🚪
4.6.3.2. Phase 1 🦋
okay so Phase 1 is where the CAC decision gets made 💅 and it's based on info the bestie downstream Bandwidth Brokers send back. That info could come from the next hop Bandwidth Broker, or from all of the Bandwidth Brokers downstream to the destination. Iconic flexibility 🌸
There are two main signaling approaches between Bandwidth Brokers for the Informed Admission case, and they're drawn out in figure 10 ✨
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 2 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 4 | BB2 | 3 | BB3 |
| |<--------| |<--------| |<--------| |
| | | | | | | |
| | | | | | | |
+-------+ +-------+ +-------+ +-------+
A)End-to-end signaling
+-------+ +-------+ +-------+ +-------+
| | | | | | | |
| |RAR | | 1 | | 3 | |
| User |-------->| |-------->| |-------->| |
| | RAA | BB1 | 2 | BB2 | 4 | BB3 |
| |<--------| |<--------| |<--------| |
| | 7 | | 6 | | 5 | |
| |<--------| |<--------| |<--------| |
+-------+ +-------+ +-------+ +-------+
B) Immediate response signaling.
Fig. 10 -- Fundamental Signalling Approaches- End to End signaling 🧚 A RAR goes from the User to BB1, and BB1 forwards it on to BB2 (1). BB2 then passes the request along to BB3 (2). If BB3 is the destination of the request, BB3 authorizes it and replies to BB2 (3). BB2 replies to BB1 (4), and then BB1 sends a Resource Allocation Answer (RAA) back to the User to wrap up the authorization. ✨
- Immediate response signaling 💜 This is when BB1 wants to authorize an RAR from its own domain, so it forwards the authorization request to BB2 (1). If BB2 approves, the response comes straight back to BB1 (2), and BB1 sends an RAA back to the User. If the authorization was positive, BB2 forwards a request on to the next BB, which is BB3 (3). BB3 authorizes the request and responds to BB2 (4). If that response is negative (5), BB2 cancels the authorization it previously issued to BB1 (6), and that cancellation then goes from BB1 to the User (7). In this case, the RAA authorization stays valid until it's revoked by 7. 💀
4.6.4. Bandwidth Broker Communication Architecture 🏗️
figure 11 shows the parts of the Bandwidth Broker architecture and the interfaces they use 👑
- An intra-domain interface lets the Bandwidth Broker talk to all the service components inside the network it controls. 🌈
- An inter-domain interface lets Bandwidth Brokers from different autonomous networks talk to each other. 🦋
- A user/application interface lets someone manage the Bandwidth Broker by hand. Requests can come from the User or from a host application. 🎀
- A policy manager interface lets you do complex policy management or admission control. 🧚
- A routing table interface helps the Bandwidth Broker understand the network topology. 🗺️
- An NMS interface handles coordinating network provisioning and monitoring. 📡
adjacent BB <---------------------------> adjacent BB
|
V
+------------------------------+
| | inter-domain | |
| -------------- ------|
application | | PM |
server \ | |iface |
\ |------- ---------+ ------|
->| user/ | | simple | ------|
user/host-->| app | | policy | | NMS |
->| iface | | services| |iface |
/ |------- ---------+ ------|
network / | |
operator | ------- ------- |
| | data | |routing| |
| | store | |info | |
| | | | | |
| ------- ------- |
| |
| ---------------- |
| | intra-domain | |
+------------------------------+
^
|
edge router(s) <---------------------------> edge router(s)
Fig. 11 -- Bandwidth Broker Architecture4.6.5. Two-Tier Inter-Domain Bandwidth Broker Communication Model 🎀
4.6.5.1. Session Initialization 🌸
before Bandwidth Brokers can set up services between two neighbouring domains, they have to establish and initialize a relationship 🫶 No authentication is used here, so any trust relationship is implicit. Part of the setup is swapping topology info, which is the list of adjacent Bandwidth Brokers 🗺️
4.6.5.2. Service Setup ⭐
the Bandwidth Broker needs to be configured first, based on agreed bi-lateral service levels 🤝 All resources allocated to a given level of provisioned service have to be reserved in each domain.
A Service Setup Request (SSR) gets generated (on demand by the operator, or at system startup) and forwarded to a downstream Bandwidth Broker. The downstream Bandwidth Broker checks it for consistency with its own service level specifications, then replies with a Setup Answer message (SA) containing its agreements. This exchange confirms and identifies the pre-established service authorization levels 💅
4.6.5.3. Service Cancellation 🙅♀️
A Service Cancellation (SC) message can cancel a service authorization. The operator can start this, or it can be triggered by an expiration date. A Cancellation Answer (CA) is sent back in return. 🥀
4.6.5.4. Service Renegotiation 🔁
An (optional) Service-Renegotiation message (SR) lets a Bandwidth Broker renegotiate an existing service. It can be started by the operator, or automatically once a certain threshold is hit. Renegotiations happen within the margins of a pre-established authorization 📏
4.6.5.5. Resource Allocation Request and Resource Allocation Answer 🍓
An RAR allocates a requested level of service on behalf of the User, and when resources are available it decides whether to admit that User to the service. A Bandwidth Broker can receive an RAR through either the intra-domain or the inter-domain interface. The RAR has to refer to the Service SetUp Identification (SSU_ID), which ties the request to a specific authorization 🔗 A Resource Allocation Answer (RAA) either confirms or rejects a request, or it can say the request is in an "in progress" state ⏳
4.6.5.6. Session Maintenance 💓
A certain level of session maintenance is required to keep Bandwidth Brokers aware of each other. This has to be implemented with time-outs and keep-alive messages, which helps Bandwidth Brokers notice when another Bandwidth Broker disappears 👀
4.6.5.7. Intra-domain Interface Protocol 🔌
The Intra-domain interface protocol used between a Bandwidth Broker and the routers it controls may be COPS, SNMP, or Telnet Command Line Interface 💻
4.7. Requirements 📋
From all the descriptions above, we can pull out the following requirements 🫶
- The Authorization mechanism may require trust relationships to be established before any requests can be made from the User to the Service Provider. Right now, trust relationship establishment is implicit. 🤷♀️
- A confirmation of authorization is required in order to initialize the system. ✅
- A negation of static authorization is required to shut down certain services. 🛑
- A renegotiation of static authorization is required to alter services (SLS's). ✏️
- Dynamic authorization requests (RAR) must fit into pre-established static authorizations (SLS's). 📦
- Dynamic authorization requests (RAR) may be answered by an "in progress state" answer. ⏳
- Provisions must be made to allow reconstruction of authorization states after a Bandwidth Broker re-initializes. 🔄
5. Internet Printing 🖨️
The Internet Printing Protocol, IPP [14], has some potentially complex authorization requirements, especially with the "print-by-reference" model 🧐 The following tries to describe some possible ways an authorization solution for this part of IPP might work, and to relate them to the framework described in [2]. This is not a product of the IPP working group. It's only meant to illustrate some authorization issues, so we can establish requirements for a "generic" protocol that supports AAA functions across many applications 💜
IPP print-by-reference lets a user ask a print service to print a particular file 🌈 The user creates a request to print a particular file on a printer (or on one of a group of printers). The key thing is that the request only includes the file name, not the file content 📄 The print service then has to read the file from a file server before printing. Both the file server and the print server must authorize the request 🔐 Once it's started, printing happens without the user getting involved. In other words, the file goes directly to the print service rather than going through the user to the printer ✨
5.1. Trust Relationships 🤝
Okay so the Printer and the File Server might be owned and run by totally different organizations, bestie 😭. There seem to be two models for how the "agreements" can get set up 👀.
- User has agreement with Print Server; Print Server has agreement with File Server.
- User has agreements with both File and Print Server directly.
In case 1, the user has a trust relationship with the Print Service AAA Server. The Printer forwards the request to the File Server. The File Server authorizes the Printer and decides if the Printer is allowed to access the file. Lowkey, there could be some cases where a Print Server is allowed to touch files on its own (maybe some "public files", or stuff that can only be printed on certain "secure" printers) 🖨️. But usually files are tied to users and not to printers, so this is not a good "generic" model, because it makes the print service an attractive point of attack 💀.
+------+ +----------------------+
| | | File Service |----+
| | | AAA Server |<-+ |
| | +----------------------+ | |
| | | | | |
| | | File Server | | |
| | | | | |
| User | +----------------------+ | |
| | | |
| | | |
| | | |
| | +----------------------+ | |
| |------>| Print Service |--+ |
| |<------| AAA Server |<---+
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 12 -- Case 1
User authorizes with Print Service.
Printer authorizes with File Service.In case 2, the user has to have a trust relationship with both the file and print services so that each one can verify the service that's right for the User 🫶. Here, the User first contacts the File Service AAA Server and asks it to enable authorization for the Print Service to access the file. There are different ways this can happen. For example, the File Service AAA Server might hand the User a token, which can then be presented to the File Server (via the Print Service) to unlock access 🔑.
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| | +----------------------+
| |
| | +----------------------+
| | | File Server |
| User | +----------------------+
| | /|\ |
| | | |
| | | \|/
| | +----------------------+
| |------>| Print Service |
| |<------| AAA Server |
| | +----------------------+
| | | Print Server |
| | | and Printer |
+------+ +----------------------+
Fig. 13 -- Case 2
User authorizes File and Print Service.
Must create binding for session between
Print Service and File Service.5.2. Use of Attribute Certificates in Print-by-Reference 🏷️
The print-by-reference case is a great example of attribute certificates in action, as discussed in [2] ✨. If we describe case 2 above using attribute certificates (ACs), we get the diagram in figure 14.
+------+ +----------------------+
| |------>| File Service |
| |<------| AAA Server |
| |Get AC +----------------------+
| |
| | +----------------------+
| | | File Server |----+
| | | |<-+ |
| User | +----------------------+ | |
| | | |
| | +---authorize passing AC | |<---Create session
| | | | | Using AC
| | V +----------------------+ | |
| |------>| Print Service | | |
| |<------| AAA Server | | |
| | +----------------------+ | |
| | | Print Server |--+ |
| | | and Printer |<---+
+------+ +----------------------+
Fig. 14 -- Using Attribute Certificates in IPP AuthorizationSo in this case, the User gets an AC from the File Service's AAA Server 🎀. It's signed by the File Service AAA Server and holds a set of attributes that describe what the holder of the AC is allowed to do. Then the User authorizes with the Print Service AAA Server and passes along the AC in that authorization request. The Printer sets up a session with the File Server and hands it the AC. The File Server trusts the AC because the File Service AAA Server signed it, and then it either allows or disallows the session 💅.
It's interesting to note that an AC could also be created and signed by the User, and then passed from the Print Server to the File Server. In that case, the File Server would need to be able to recognize the User's signature 🧐. Yet another option is that the Print Service AAA Server could just authenticate the User and then ask the File Service AAA Server for an AC 💜.
5.3. IPP and the Authorization Descriptive Model 📋
The descriptive model in [2] has four basic elements: User, User Home Organization, Service Provider AAA Server, and Service Equipment 🧩.
When we map these onto IPP, the User stays the same, and so does the User Home Organization (if it's included) ✨. The Service Provider AAA Server and the Service Equipment are expected to be closely coupled on the same processor. In other words, the interface between the Print Service AAA Server and the Printer, and the one between the File Service AAA Server and the File Server, are internal. They won't require a formal protocol, although some standard API might be useful 🛠️.
The concept of a Resource Manager (see [2]) has some interesting twists when it comes to IPP 🌀. Once the job starts, the user isn't involved in the service anymore. But until printing is done, it seems useful for any of the parties in the authorization process to be able to ask for status or cancel the print session 🙅♀️. The user needs a way to "bind" to a particular session, and may have to reauthorize to get access to Resource Manager information 🔐.
6. Electronic Commerce 💳
This section covers the authorization side of an e-commerce architecture that's typically used in Europe 🇪🇺. We'll use this model to figure out the contractual and trust relationships and the message exchanges. After that, we'll pull out a set of authorization requirements for e-commerce 📝.
Most e-commerce protocols focus on authentication and message integrity, but e-commerce exchanges, as described by the Internet Open Trading Protocol (trade) Working Group in [15], also involve authorization 🦋. This section looks at one e-commerce protocol called SET (Secure Electronic Transaction), which handles credit and debit card payments 💖. We'll analyze the authorization aspects from an architectural viewpoint, using the concepts and terms defined in [2].
We are not proposing SET as a standard authorization protocol, bestie 🙅♀️. We're looking at the SET model as a way to understand the e-commerce problem domain, so that we can derive the requirements an authorization protocol would need to meet in order to be used in that domain 🌸.
E-commerce protocols and mechanisms like the ones described in [16] may not only matter for letting customers shop safely in Cyberspace, but may also matter for buying Internet services 🌐. With emerging technologies that let Internet transport services be differentiated, a more complex pricing model will be needed, along with additional payment methods 💸. Flexible authorization of services will be a big deal for things like letting globally roaming users ad hoc allocate premium bandwidth with an ISP that's authorized to accept certain credit card brands 🌈.
6.1. Model Description 🧠
Building the model involves four steps:
- identification of the components that are involved and what they are called in this specific environment,
- identification of the relationships between the involved parties that are based on some form of agreement,
- identification of the relationships that are based on trust, and
- consideration of the sequence of messages exchanged between components.
6.1.1. Identification of Components
Okay so, we're going to look at the components of an electronic commerce transaction through the conceptual entities defined in [2]. Let's go! 💖
- Cardholder (User) -- the person or organization that is to receive and pay for the goods or services after a request to purchase has been received. In SET terms this is called a Cardholder. 🎀
- Issuer (User Home Organization) -- the financial organization that guarantees to pay for authorized transactions to purchase goods or services on behalf of the User when using a debit or credit card it issues. The financial organization (typically a bank or Brand Organization) will transfer money from the user account to the account the party to which the User instructs it to send the payment. The issued card authorizes the User to use the card for payments to merchants who are authorized to accept the card. In SET terms this organization is called the Issuer. This organization is considered "home" to the Cardholder. 🏦✨
- Merchant (Service Provider) -- the organization from whom the purchase is being made and who is legally responsible for providing the goods or services and receives the benefit of the payment made. In SET terms this organization is called a Merchant. The Cardholder is considered to be "foreign" to the Merchant. 🛍️
- Acquirer (Broker) -- the organization that processes credit or debit card transactions. Although in reality this function may be rather complex and may span several organizations, we will simply assume this organization to be a Brand Organization fulfilling the role of the Acquirer as defined in SET. The Acquirer establishes an account with the Merchant. The Acquirer operates a Payment Gateway that will accept payment authorization requests from authorized merchants and provide responses from the issuer. The Acquirer will forward an authorization request to the Issuer. The Acquirer is considered "home" to the Merchant. 🌈
As the SET document [16] notes, a Brand Organization (credit card organization) may handle both the Issuer function and Acquirer function that operates a Payment Gateway. For simplicity, we therefore assume that the authorization role of Broker (Acquirer) and User Home Organization (Issuer) both belong to the Brand Organization. 🫶
In order to be more descriptive, we now use the SET terms. In the requirements section these terms are mapped back into the authorization framework terms again. 🧚
6.1.2. Identification of Contractual Relationships
Contractual relationships are illustrated in figure 15, below. 📝
- The Cardholder has a contractual relationship with the card Issuer. The Cardholder holds an account with the Issuer and obtains an account number. 💳
- The Merchant has a contractual relationship with the Acquirer. The Merchant obtains a Merchant ID from the Acquirer. 🍓
- In the real world there may be no direct contractual relationship between the Issuer and the Acquirer. The contractual relationships allowing an Acquirer to relay a payment authorization request to an Issuer may be very complex and distributed over multiple organizations. For simplicity, however, we assume there are contracts in place allowing an Acquirer to request payment authorization from an Issuer. These contracts are facilitated by the Brand Organization. Therefore, in our simplified example, the Acquirer and Issuer belong to the same Brand Organization. The Acquirer operates a Payment Gateway for which it needs a Bank Identification Number (BIN). 🙈
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |=======| | Payment | |
| | | | Gateway | |
| | | +------------------+ |
| | | |
+----------------+ +------------------------+
|| ||
|| ||
|| ||
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| | | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +----------------------+
Fig. 15 -- SET Contractual Relationships6.1.3. Identification of Trust Relationships
It is important to recognize that there are two kinds of trust relationships: static and dynamic trust relationships. 🔐 Static trust relationships in SET are established by means of a registration process that will request a certificate to be issued to the party that needs to be trusted and authorized to be part of a SET transaction. Dynamic trust is created at the time of a payment transaction and its subsequent authorization request. Note that at the issue phase of a certificate, based on identification and registration, the user of the certificate gets an implicit static authorization and a means of authenticating and securing messages. For this purpose a Certificate Authority (CA) will issue certificates that are used to sign and/or encrypt messages exchanged according to the SET protocol. 🦋
6.1.3.1. Static Trust Relationships
In the discussion that follows, refer to figure 16, below. 👑
+-------+
| Root |
| CA |
+-------+ CA = Certificate Authority
| {C} = Certificate
|
+-----------------+
| Brand |
| CA |
+-----------------+
| | |
| | +-------+
| | |Payment|
+----------------+ | | |Gateway| +----------------------+
| Issuer | | | | CA | | Acquirer |
| (User Home | +----------+ | +-------+ | (Broker) |
| Organization) | |Cardholder| | | | +----------------+ |
| | | CA | | +------+--+-{C} Payment | |
| | +----------+ | 3 | | Gateway | |
| | | | | +----------------+ |
| | | +---------+ | |
+----------------+ | | Merchant| +----------------------+
| | CA |
| +---------+
| |
+----------------+ | | +--------------------+
| Cardholder | | | | Merchant |
| (User) | | | | (Service Provider) |--+
| {C}-+-----+ | | | |
| | 1 +-----------+-{C} | |
| | 2 | | |
| | | | |
| | +--------------------+ |
| | | |
| | | Fulfillment |
| | | |
+----------------+ +---------------------+
Fig. 16 -- SET Trust Relationships within a Brand Domain- The Brand Organization operates a Brand CA and is therefore the holder of the common trust within the described domain. All involved parties (Cardholder, Issuer, Merchant and Acquirer) are members of the same trust domain. We will identify three separate CA's which issue a certificate on behalf of the Issuer, the Acquirer and the Brand Organization. The Brand CA, according to a tree like hierarchy, certifies all underlying CA's. The Brand CA obtains its trust from a single Root Certificate Authority. Before any party can obtain a Certificate from a CA, the party must have some form of contractual relationship. 🌸
- After an account has been established with the Issuer, the Cardholder has to register with a Cardholder CA (CCA) through a series of registration steps (1) as defined in the SET protocol. If the CCA approves the registration, the Cardholder will obtain a Cardholder Certificate. The CCA may be operated by the Brand Organization on behalf of the Issuer. The Cardholder Certificate is an electronic representation of the payment card. This process creates a trust relationship between the Cardholder and the Brand. After the cardholder has received the Cardholder Certificate, the Cardholder is authorized to perform payments to an authorized Merchant. 💅
- After the Merchant has obtained a Merchant ID from the Acquirer, the Merchant has to register with the Merchant CA (MCA) through a series of registration steps (2) as defined in the SET protocol. If the MCA approves the registration, the Merchant will obtain a Merchant Certificate. This process creates a trust relationship between the Merchant and the Brand. The MCA may be operated by the Brand Organization on behalf of the Acquirer. After registration, the Merchant is authorized to accept payment requests from Cardholders and to send authorization requests to the Acquirer's Payment Gateway. 🧁
- After the Acquirer has obtained a valid Bank Identification Number (BIN), the Acquirer must register with the Payment Gateway CA (PCA) in order to obtain a Payment Gateway Certificate (3). The Payment Gateway Certificate authorizes the Gateway to accept payment authorization requests originating from Merchants within its trust domain. 🔥
- The Acquirer and Issuer have a trust relationship via the Brand Organization. The trust relationship is not ensured by procedures or a mechanism defined by SET, as this is a problem solved by agreements between financial organizations facilitating the payment service. Again, for simplicity, we assume that the relationship ensures that payment authorization requests received by the Acquirer's gateway will be forwarded in a secure and efficient way to the Issuer and its response is handled in the same way. 🌈
6.1.3.2. Dynamic Trust Relationships ✨
okay so there's no static trust relationship between the Cardholder and the Merchant 😭 a Cardholder doesn't have to register with a Merchant, and a Merchant doesn't have to register with a Cardholder either. the trust shows up in the moment, during the communication itself, and it's based on the shared connection to the Brand 🎀 the Cardholder's software can use digital signatures (public key cryptography, btw 🔐) to check that the Merchant is allowed to take the Brand Organization's credit card, and the Merchant can check that the Cardholder is allowed to use it. the whole thing is giving "we met at a party and instantly had mutual friends" 💅
6.1.4. Communication Model 🦋
the purchase request from the Cardholder to the Merchant, plus the payment authorization exchange between the Merchant and the Acquirer, is shown in figure 17 and walked through below 🌸
+----------------+ +------------------------+
| Issuer | | Acquirer |
| (User Home | | (Broker) |
| Organization) | | +------------------+ |
| |<------+--| Payment | |
| | 5 | | Gateway | |
| |-------+->| | |
| | 6 | +------------------+ |
| | | /|\ | |
+----------------+ +---------+---+----------+
|4 |7
| \|/
+----------------+ +--------------------+
| Cardholder | | Merchant |
| (User) | | (Service Provider) |---+
| |------>| | |
| | 1 | | |
| |<------| | |
| | 2 | | |
| |------>| | |
| | 3 | | |
| |<------| | |
| | 8 | | |
| | | | | |
| | +-----------------+--+ |
| | | |9 |
| |<--------| Fulfillment \|/ |
| | 10 | |
+----------------+ +----------------------+
Fig. 17 -- Communication Sequence- the Cardholder goes shopping and decides to buy some stuff from merchant.com 🛍️ they've picked a list of goods, and the Merchant's software has made an order form showing the price, the terms and conditions, and which payment methods are accepted 💖 the SET transaction officially starts the moment the Cardholder says "I want to pay with this brand." then the Cardholder software sends a request to the Merchant to kick off the payment process ✨
- the Merchant checks the order, signs it, and sends it back to the Cardholder 📝 it also includes a certificate from the Acquirer's Gateway, so the Cardholder can encrypt the payment instructions that only the Gateway should read (like the credit card info), not the Merchant 🔒 the Cardholder also includes their own certificate 🎀
- the Cardholder checks both certificates (the software already has the CA's root certificate 🙌) 🔍 then the Cardholder software makes a message with the order info and payment instructions and signs it as the Cardholder. using the Gateway Certificate, it encrypts the Payment Instruction so only the Gateway can read it 🫶 the Cardholder also includes their certificate 💜
- the Merchant checks the Cardholder's certificate and makes sure the message hasn't been messed with 🧐 then they process the payment and send a payment authorization request to the gateway 💸 that request has the Cardholder's certificate and both Merchant certificates 📜
- the Gateway checks the Merchant's signature certificate and confirms the Merchant signed the authorization request ✅ then it gets the account info and payment instructions, checks message integrity, and checks the Cardholder's certificate too 👀 if everything looks good, it sends an authorization request to the Issuer over a secure bank network 🏦
- the Issuer sends back the authorization 💅
- the Acquirer's Gateway makes an authorization response, and it includes the gateway's certificate 🎀
- the Merchant checks the authorization response and wraps things up by forwarding a purchase response to the Cardholder 🌈
- the Merchant software gives the green light for the purchased goods to be delivered 🚚
- the Cardholder gets their goods 🥳 it's over, it's so over (in the best way) 👑
6.2. Multi Domain Model 🌍
in the earlier "single" domain case, we already assumed there are multiple Cardholders, Merchants, Issuers, and Acquirers 💕 but they all belong to one trust domain, because there's only one CCA, one MCA, and one PCA. the trust between many Cardholders and many Issuers goes through that one CCA, and the trust between an Acquirer and a Merchant goes through the same MCA 🦋 the multi-domain case happens when there are multiple domains of CCAs, MCAs, and PCAs. in SET, those domains sit under a particular Geopolitical CA (GCA), which is shown in figure 18 🗺️
+-----------+
| Root CA |
| |
+-----------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Brand CA | |
| |-+
+-----------------------------------------------------+
|
|
+----------------------|-------------------------------+
+-----------------------------------------------------+ |
| Geopolitical CA | |
| |-+
+-----------------------------------------------------+
| | |
| | |
+----|--------+ +---|-------+ +-------|----------+
+------------+ | +----------+ | +-----------------+ |
| Cardholder | | | Merchant | | | Payment Gateway | |
| CA |-+ | CA |-+ | CA |-+
+------------+ +----------+ +-----------------+
Fig. 18 -- SET Certificate Management Architecturea GCA can stand for a country or a region 🌏 the architecture sets up a trust hierarchy for managing and verifying SET Certificates, since they need to be issued, renewed, or revoked 📋 each geopolitical region can have its own policies for issuing, renewing, or revoking certificates 🙃 but once certificates are issued, Cardholders and Merchants from different GCAs can still be recognized as part of the same Brand 🤝 that means a European Cardholder can buy stuff in the U.S. 🇺🇸 the U.S. Acquirer's gateway will recognize that the Cardholder is in the same Brand and will accept the payment authorization request 🎉
6.3. Requirements 📋
ngl, lots of e-commerce doesn't use SET 😅 other options exist that are based on SSL, XML, and S/MIME 💻 there's also a setup called half SET, which uses SET only for the payment authorization to the Gateway 🦋 still, using the model in this document, we can work out a pretty complete set of protocol requirements for e-commerce 💜 here the SET terms get swapped out for the descriptive model terms:
Cardholder = User
Merchant = Service Provider
Issuer = User Organization
Acquirer = Broker- the Authorization mechanism must allow trust relationships to be set up before any requests can be made from the User to the Service Provider, and from the Service Provider via a Broker to the User Organization 🔐 this process lets the parties talk securely by creating an authenticated channel, and in doing so it implicitly authorizes its use ✨
- whenever any request or response comes in, entities need to be able to verify whether the sending party is still authorized to send it 👀
- the User must be able to authorize the Service Provider to request an authorization from the User Home Organization 🎀
- the User must be able to authorize fulfillment of a proposed service offer from the Service Provider 💅
Other requirements related to the authorization process:
Integrity 🧁
- for any authorization request or response, the receiving party needs to verify that the content of the message hasn't been altered 🫶
Confidentiality/Privacy 🙈
- the User must be able to pass information relevant to the session authorization process to the User Home Organization via a Broker and the Service Provider, without letting the Broker or the Service Provider look inside its content 🤫
- the User Home Organization must be able to send information relevant to the session authorization via the Broker and the Service Provider to the User, without letting the Broker or the Service Provider look inside its content 🌸
Nonrepudiation 📜
- there's a need for a recorded, authenticated, and authorized agreement about the request for and delivery of the service 💖
7. Computer Based Education and Distance Learning 🎓✨
this section is about the authorization side of computer based distance learning environments 💻 we're modeling the relationships and working practices at a hypothetical university, where a student enrolls in courses, goes to lectures, and takes exams from remote locations (distance learning) or on computer equipment (computer based education) 🦋 when a student finishes successfully, they're authorized to enroll in a set of later courses based on their curriculum requirements 📚 finishing the required courses with passing grades means graduation 🎓👑
this section uses a student taking courses at a faculty (department) of the university as its example, but the resulting requirements should also apply to other applications in similar environments, e.g. library loans, electronic abstract and reprint services, computer and network access, use of copy machines, budget management, store retrievals, use of coffee machines, and building access ☕🌈 lol the coffee machine is in there 🙈
it's important to realize that the AAA environment we're describing also needs to be managed 🛠️ for example, for something like budget management, budget authority has to be delegated from a central financial department to budget managers in education or faculty groups 💰 an AAA environment must allow policy rules to be created either by certain individuals or by other AAA servers that have authorization to do so 🔥
7.1. Model Description ✨
okay so the set-up happens in four steps, and I'm going to walk you through each one bestie 💅
- identification of the components that are involved and what they are called in this specific environment,
- identification of the contractual relationships between the involved parties,
- identification of the relationships that are based on trust, and
- consideration of the sequence of messages exchanged between components.
7.1.1. Identification of Components 🎀
okay, we're gonna look at the components of a distance learning environment through the lens of the conceptual entities defined in [2]. let's meet the cast 🧚
- The Student (User) -- the person enrolling in a course (Service) and taking the corresponding exam. main character energy 👑
- The Educator (Service Equipment) -- the education content server for which the content is delivered by the Professor. 💻
- The Educator Authorization Module (Service Provider AAA Server). this module must check at the service access point whether the student complies with the requirements for enrolling in the course. the authorization may be based on both local (by the professor) and remote policies (originating from the faculty). rules must allow enough flexibility to prevent students from being falsely denied access to courses. strict rules must only be applied at graduation time. 🫶
- The Faculty (Service Provider) -- the organization (department in U.S. terms) which controls the Service "Equipment" of which the Educator is one example. 🏫
- The Curriculum Commission (Part of User Home Organization) -- body responsible for creating rules by which a student is allowed to enroll in a certain course and how this course will count toward his or her graduation requirements. students may legally take any course available at any time, however the Curriculum Commission will decide whether this course will contribute towards their graduation. when a Student registers with a certain Educator, the Educator may check with the Curriculum Commission AAA server whether the course will count towards graduation and confirm this with the student. 📚
- The Student Administration (Part of User Home Organization) -- the administrative organization that authorizes students to enroll in courses if certain criteria, including financial criteria, are met. next to the student, the Student Administration will keep track of any exam results for the student and will issue a graduation certificate when all criteria are met. 🎓
7.1.2. Identification of Contractual Relationships 📜
the contractual relationships are shown in figure 19 below. based on those contracts, specific trust relationships get created as required.
the original figure is not drawn here, but it is assumed that the university has contractual relationships with the faculties, and every faculty is allowed and obligated to build, maintain and present one or more specific studies. 🌸
+---------------------------------------------+
| +-----------------------------------------+ |
| | Faculty administration | |
| |+----------------+ +----------------+| |
| |O Student | | Curriculum || |
| *| Administration O*****O Commission || |
| *| AAA Server | | AAA Server || |
*/|+---O------O-----+ +-----O------O---+| |
*//| * * * * | |
*// +----*---------*-----------*---------*----+ |
*//| * || * * || * |
*// | * || * * || * |
*// | * || * || * |
*// | * || * * || * |
*// | * || * * || * |
*// | +----*---------*--+ +--*---------*----+ |
*// | | * * | | * * |
*// | |+---O------O----+| |+----O------O---+| |
*// | || Educator A || || Educator B || |
*// | || AAA Server || || AAA Server || |
*// | || Service admin.|| || Service admin.|| |
*// | |+---O-----------+| |+-----------O---+| |
*// | | * | | * | |
+-O-------+ | | * | | * | |
| | | |+---O-----------+| |+-----------O---+| |
| Student | | || Educator || || Educator || |
| | | || Course A || || Course B || |
| | | |+---------------+| |+---------------+| |
+---------+ | +-----------------+ +-----------------+ |
| Faculty |
+---------------------------------------------+
// = contractual relationship
** = trust relationshipFig. 19 -- Contractual relationships - single domain case
so, as figure 19 shows, the Student has a contractual relationship with the Faculty. that contract lets the Student pursue a course of study made up of a set of courses. the Educators present those courses to the Students, and a course of study can include courses from different Faculties. 🦋
faculties also have contracts with each other, which let Students from one Faculty enroll in courses from other Faculties. 🌈
faculties set up Educators based on a contract between the Faculty Administration and the professor who implements and manages the Educator. authorization runs on policy rules defined by one or more parties in those contractual relationships. for example, a professor has a policy to give the course only in the afternoon, and the Faculty has a policy to give the course to their own students and students from faculty-x, but not (when it's oversubscribed) to faculty-y students. 🙈
7.1.3. Identification of Trust Relationships 🔐
figure 19 shows the relevant trust relationships that statically let AAA entities communicate certain attributes in our simplified example. however, for the pictured entities to work, other trust relationships that aren't pictured must already exist:
- a trust relationship based on a contract between the Faculty and the university lets a faculty create and teach specific courses that belong to a course of study. 🍓
- although it's not detailed further in this example, trust relationships between faculties authorize students from one faculty to enroll in courses with other faculties. 💜
- a professor responsible for the content of the Educator has a trust relationship with the administration of the faculty. through this relationship, the faculty lets the professor teach one or more courses that fit the requirements of the Curriculum Commission. ✨
figure 19 shows the following trust relationships:
- when a person wants to become a Student of a Faculty, the contract requires the Student to register with the Student Administration of the Faculty. if the registration requirements are met, a trust relationship with the Faculty lets the Student register for courses. for this, the Student Administration issues a student card that contains a student ID and information about the Faculty the student is admitted to. the Student Administration only admits Students who pay the necessary fees and have met certain prerequisites. it also keeps track of Student grades and ultimately issues a certificate at graduation. the Student Administration AAA server has access to relevant student data, and it only issues grade information and other student-related information to authorized parties that have a specified means of authenticating. 🎓
- the Curriculum Commission AAA server needs a trust relationship with the Student Administration AAA server so it can get grade information and check whether a student has met the required course prerequisites. the Curriculum Commission creates certain rules within its AAA server, which get evaluated when a particular student tries to register for a particular course, so it can give the student an advisory. 🧠
- the Educator AAA server needs a trust relationship with the Student Administrator AAA server so it can verify whether this particular Student is in good standing with the Faculty. only authorized Educator AAA servers may send requests to the Student Administration AAA server. 🔒
- the Educator AAA server needs a trust relationship with the Curriculum Commission AAA server so the Educator can get an advisory for the Student on whether this course fits his or her curriculum or whether the student meets the course prerequisites. only authorized Educator AAA servers may send requests to the Curriculum AAA Server. 🌟
7.1.4. Sequence of Requests ✨
okay so to keep things simple 💅 we're following a student from the same faculty as the professor, which is the cleanest example ever 🎀 Here's how the interactions go for a hypothetical course (check figure 20 🦋):
+----------------------------------------------+
| |
| +----------------+ 6 +----------------+ |
| | Student |----->| Curriculum | |
| | Administration |<-----| Commission | |
| | AAA Server | 5 | AAA Server | |
| +----------------+ _ +----------------+ |
| /|\ | /|/ |
| | | / / |
| 2,8| |3 / /6 |
| | | 4/ / |
| | | / / |
| | | / / |
| | \|/ /|/ |
| +---------------+ -- +---------------+ |
| | Educator A | | Educator B | |
| | AAA Server | | AAA Server | |
| +---------------+ +---------------+ |
| /|\ | |
|2,4,8| |3,6 |
+---------+ | | \|/ |
| | 1,7 | +---------------+ +---------------+ |
| Student |------->| Educator | | Educator | |
| |<-------| Course A | | Course B | |
| | 7,8 | +---------------+ +---------------+ |
+---------+ | Faculty |
+----------------------------------------------+
Fig. 20 -- AAA transactions - single domain case- First up 🌸 the Professor sets up the Service Equipment (Educator), and then students roll up presenting their ID (college card, name+faculty) and ask to be let into the course 🎓
- The Educator checks the ID to make sure it's really a student from the faculty 🔍 This can include a check with the Student Administration.
- The Student Administration answers the Educator AAA Server, and the Educator AAA Server passes it back to the Educator 📨
- The Educator checks the student's request against its own policy (courses only in the afternoon ☀️) and asks the Curriculum Commission whether this student is advised to take the course 🧐 The necessary information is not normally known to or maintained by the professor 🙈
- The Curriculum Commission may check against the Student Administration to see if the Student had the necessary grades for the previous courses, according to the policies set by the Curriculum Commission 📚
- The Student Administration replies to the Curriculum Commission, the Curriculum Commission replies to the Educator AAA Server, and the Educator AAA Server replies to the Educator 🔁
- If now authorized 🎉, the Student is presented the material and the Student returns completed exams ✍️
- If the Student passes the tests 🏆, the Educator informs both the Student and the Student Administration that the Student has passed 💖
7.2. Requirements 📋
okay so these are the requirements we came up with for an AAA server environment for this example:
- It MUST be possible to delegate authority to contracted partners. Although this requirement is not explicit in the limited example, the relationship between University and Faculty may require delegation of authority regarding the curriculum to the Faculty. In the case of budget management, this requirement is evident 💼
- A system to manage the delegated authority MUST be established. It is possible that this is just another AAA server environment. This comes from the fact that one partner requires the presence of specific rules to be in the AAA server of another partner. For example, the Faculty MUST be sure that certain checks are performed by the Educator's AAA server 🔐
- AAA requests MUST either be evaluated at the AAA server queried or else parts of the request MUST be forwarded to another AAA server which can decide further on the request. As such, it MUST be possible to build a network of AAA servers in which each makes the decisions it is authorized to make by the relationships among the entities, e.g., a request from the Educator to the Curriculum Commission may result in a request to the Student Administration 🕸️
- Transaction logs MUST be maintained to support non-repudiation for the grades of the students. This recording SHOULD be time-stamped and allow signing by authorized entities. A student SHOULD sign for taking an exam and this SHOULD be kept by the Educator's AAA server. After grading, the professor SHOULD be able to sign a grade and send it to the Student Administrator, and the Student Administrator's AAA server SHOULD log and timestamp this event 🧾
- Three types of AAA messages are REQUIRED:
- authorization requests and responses for obtaining authorization,
- notification messages for accounting purposes, and
- information requests and responses for getting information regarding the correct construction of requests and for querying the database of notifications. 💌
8. Security Considerations 🔐
okay this part is SERIOUS bestie 😭 The authorization applications discussed in this document are modeled on the framework presented in [2]. Security considerations relative to the authorization framework are discussed in [2].
Specific security aspects of each authorization application presented in this document are discussed in the relevant section, above. Security aspects of the applications, themselves, are discussed in the references cited below.
Glossary 📖
- Attribute Certificate -- a structure containing authorization attributes, digitally signed using public key cryptography 🔏
- Contract Relationship -- a relation established between two or more business entities, where terms and conditions determine the exchange of goods or services 🤝
- Distributed Service -- a service that is provided by more than one Service Provider acting in concert 🌐
- Dynamic Trust Relationship -- a secure relationship dynamically created between two entities who may never have had any prior relationship. This relationship can be created if the involved entities have a mutually trusted third party. Example: A merchant trusts a cardholder at the time of a payment transaction because they both are known by a credit card organization 💳
- Policy Decision Point (PDP) -- the point where policy decisions are made 🧠
- Policy Enforcement Point (PEP) -- the point where the policy decisions are actually enforced 🛡️
- Resource Manager -- the component of an AAA Server which tracks the state of sessions associated with the AAA Server or its associated Service Equipment, and provides an anchor point from which a session can be controlled, monitored, and coordinated 🎛️
- Roaming -- an authorization transaction in which the Service Provider and the User Home Organization are two different organizations. (Note that the dialin application is one for which roaming has been actively considered, but this definition encompasses other applications as well.) ✈️
- Security Association -- a collection of security contexts, between a pair of nodes, which may be applied to protocol messages exchanged between them. Each context indicates an authentication algorithm and mode, a secret (a shared key, or appropriate public/private key pair), and a style of replay protection in use. [14] 🗝️
- Service Equipment -- the equipment which provides a service 🖥️
- Service Provider -- an organization which provides a service 🏢
- Static Trust Relationship -- a pre-established secure relationship between two entities, created by a trusted party. This relationship facilitates the exchange of AAA messages with a certain level of security and traceability. Example: A network operator (trusted party) who has access to the wiring closet creates a connection between a user's wall outlet and a particular network port. The user is thereafter trusted -- to a certain level -- to be connected to this particular network port 🔌
- 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 🏠
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, C., Holdrege, M. and D. Spence, "AAA Authorization Framework", RFC 2904, August 2000.
[3] 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.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Aboba, B. and G. Zorn, "Criteria for Evaluating Roaming Protocols", RFC 2477, January 1999.
[6] Beadles, Mark Anthony, and David Mitton, "Criteria for Evaluating Network Access Server Protocols", Work in Progress.
[7] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[8] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
[9] Calhoun, P. and G. Zorn, "Roamops Authentication/Authorization Requirements", Work in Progress.
[10] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[11] Glass, Steven, et al, "Mobile IP Authentication, Authorization, and Accounting Requirements", Work in Progress.
[12] Hiller, Tom, et al., "cdma2000 Wireless Data Requirements for AAA", Work in Progress.
[13] Neilson, Rob, Jeff Wheeler, Francis Reichmeyer, and Susan Hares, "A Discussion of Bandwidth Broker Requirements for Internet2 Qbone Deployment", ver. 0.7, August 1999, http://www.merit.edu/working.groups/i2-qbone-bb/doc/BB_Req7.pdf.
[14] deBry, R., "Internet Printing Protocol/1.0: Model and Semantics", RFC 2566, April 1999.
[15] Burdett, D., "Internet Open Trading Protocol - IOTP", RFC 2801, April 2000.
[16] "SET Secure Electronic Transaction Specification Book 1: Business Description", Version 1.0, May 31, 1997, http://www.setco.org/download/set_bk1.pdf.
Authors' Addresses ✨
okay bestie, this is where we get to meet the people who wrote the whole thing 🫶 nine authors, all with their own contact deets, so here they are exactly as they were written 💅
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
Pat R. Calhoun
Network and Security Research Center, Sun Labs
Sun Microsystems, Inc.
15 Network Circle
Menlo Park, California, 94025
USA
Phone: +1 650 786 7733
Fax: +1 650 786 6445
EMail: pcalhoun@eng.sun.com
Stephen Farrell
Baltimore Technologies
61 Fitzwilliam Lane
Dublin 2
Ireland
Phone: +353 1 647 7406
Fax: +353 1 647 7499
EMail: stephen.farrell@baltimore.ie
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
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
Betty de Bruijn
Interpay Nederland B.V.
Eendrachtlaan 315
3526 LB Utrecht
The Netherlands
Phone: +31 30 2835104
EMail: betty@euronet.nl
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
Matt Holdrege
ipVerse
223 Ximeno Ave.
Long Beach, CA 90803
EMail: matt@ipverse.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.comFull Copyright Statement 🎀
okay now the legal bit, and I'm keeping this one word-for-word because it's a legal notice and it has to stay complete 🙈 it's basically saying the Internet Society owns the copyright (2000), you can copy and share this doc and make derivative works as long as the notice stays on them, you can't change the doc itself (unless it's for standards work or translating it), those permissions are forever, and the whole thing is "AS IS" with no warranties 💀
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 🌸
last one, and it's a quick one 🧚 the RFC Editor function, the team that keeps these documents in order, is currently being funded by the Internet Society ✨
📦 where this page comes from
- ietf: rfc2905 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms