RFC 2904
AAA Authorization Framework
RFC 2904 💌 AAA Authorization Framework 🎀
Network Working Group 🌸 Request for Comments: 2904 💖 Category: Informational 🍓 Date: August 2000 ✨
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.) 👑
Okay so the title block tells us this one is an Informational doc, so it's giving "here's some info" 🧚, not a binding standard. It doesn't list anything it obsoletes or updates, so it's standing on its own. 🦋
Status of this Memo ⭐
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. 💅
Copyright Notice 🌈
Copyright (C) The Internet Society (2000). All Rights Reserved. 🫶
Abstract ✨
This memo is the base requirements doc for Authorization of Internet Resources and Services (AIRS). 🔥 It lays out an architectural framework for understanding how authorization works for Internet resources and services, and from that it pulls out requirements for authorization protocols. It's literally the foundation everything else is built on 😭
Table of Contents 📋
1. Introduction ................................................ 2
2. Authorization Entities and Trust Relationships .............. 4
3. Message Sequences ........................................... 7
3.1. Single Domain Case ..................................... 7
3.1.1. The Agent Sequence .............................. 7
3.1.2. The Pull Sequence ............................... 8
3.1.3. The Push Sequence ............................... 9
3.2. Roaming ................................................ 10
3.3. Distributed Services ................................... 13
3.4. Combining Roaming and Distributed Services ............. 15
4. Relationship of Authorization and Policy .................... 16
4.1. Policy Retrieval ....................................... 16
4.2. Policy Evaluation ...................................... 17
4.3. Policy Enforcement ..................................... 17
4.4. Distributed Policy ..................................... 18
5. Use of Attribute Certificates ............................... 19
6. Resource Management ......................................... 22
6.1. Session Management ..................................... 23
6.2. The Resource Manager ................................... 24
7. AAA Message Forwarding and Delivery ......................... 25
8. End-to-End Security ......................................... 26
9. Streamlined Authorization Process ........................... 27
10. Summary of the Authorization Framework ..................... 28
11. Security Considerations .................................... 28
Glossary ....................................................... 29
References ..................................................... 31
Authors' Addresses ............................................. 32
Full Copyright Statement ....................................... 351. Introduction 🧚♀️
Okay bestie, this doc is one of a series of three documents that the AAAarch RG is looking at. They all cover the authorization requirements for AAA protocols, and they're the squad 👯♀️:
- AAA Authorization Framework (this document)
- AAA Authorization Requirements [2]
- AAA Authorization Application Examples [3]
There's a real, proven need for one common scheme that covers every Internet service that offers Authorization 🔥. This common scheme is going to handle a bunch of different functional architectures that meet the needs of basic services. We're describing those architectures and functions as a base for pulling out requirements for an authorization protocol [2]. It's giving foundation vibes 💜.
These architectures include Policy structures, Certificate Authorities, Resource Managers, Inter-Domain and Multi-Domain schemes, and Distributed Services 🌸. The requirements are about how Authorization services are expected to be used across all of these architectures.
A representative set of applications that could use this architecture for their authorization needs is in [3]. The examples in [3] show how this framework can cover a wide range of different authorization needs 🦋.
We expect this work might get extended later into a more comprehensive model, and that this scheme will end up inside a framework that also includes authentication, accounting and auditing 🍓. We've referenced a bunch of authorization sources, but we know we might have missed some that should be included 🙈. If you spot any oversight, please let one of the authors know so it can be fixed in a future revision. Bestie, we need your eagle eyes 👀✨!
Generally speaking, it's assumed that the parties taking part in the authorization process have already gone through an authentication phase 🔐. The authentication method those parties use is outside the scope of this document, except to the extent that it influences the requirements in a later authorization process. Likewise, accounting requirements are outside the scope of this document, other than recording accounting data or establishing trust relationships during an authorization that will make a later accounting phase easier 💅.
Here's the tea ☕. The work for this memo was done by a group that was originally the Authorization subgroup of the AAA Working Group of the IETF. Then the AAA working group's charter changed to focus on MobileIP and NAS requirements, so the AAAarch Research Group was chartered within the IRTF to keep going with and expand the architectural work the Authorization subgroup started. This memo is one of four that the subgroup created. 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 AAAarch subgroup and everyone else in this area can access the work, and it is not meant as a definitive description of architecture or requirements 🙅♀️.
This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their negatives, in the way described in RFC 2119 [4]. Those key words are the ones that really matter 🫶, so read them carefully!
To be continued in part 2 🌈💖
2. Authorization Entities and Trust Relationships ✨
okay so this section is where we set up our shared vocab 🎀 the whole point is giving us a framework for talking about authorization requirements across a huge number of applications. we're introducing terms for the basic elements of an authorization transaction AND for concepts that show up in all (or at least a lot of) authorization proposals 💅
Figure 1 below shows the basic conceptual entities that can be participants in an authorization 🦋
- A User who wants access to a service or resource.
- A User Home Organization (UHO) that has an agreement with the user and checks whether the user is allowed to get the requested service or resource. This entity may carry info needed to authorize the User, which might not be known to the Service Provider (like a credit limit) 💸
- A Service Provider's AAA Server which authorizes a service based on an agreement with the User Home Organization, without specific knowledge about the individual User. This agreement may include stuff that isn't relevant to an individual user (e.g., the total agreed bandwidth between the User Home Organization and the Service Provider) 🧚
- A Service Provider's Service Equipment which provides the service itself. This might, for example, be a NAS in dial service, or a Router in the QoS service, or a print server in the Internet Printing service 🖨️
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 1 -- The Basic Authorization EntitiesThese entities are what the authorization requirements will refer back to, so keep them in your back pocket 🫶
There can be bilateral agreements between pairs of organizations in an authorization transaction. These agreements can be formal contracts or Service Level Agreements, so it's giving legal and technical energy at the same time 📜 Figure 2 uses double lines to show the relationships that may exist between the User and the User Home Organization, and between the User Home Organization and the Service Provider 👀
+------+ +-------------------------+
| | | User Home Organization |
| |======| +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | ||
| | ||
| | ||
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 2 -- Service AgreementsAuthorization is based on these bilateral agreements between entities. Agreements can be chained, as shown in figure 2 🔗 The User has an agreement with the User Home Organization (e.g., the User may have access to the service between 9:00 a.m. and 11:00 a.m. daily) ⏰ The User Home Organization has an agreement with the Service Provider (e.g., that all requests for access will be granted, except between 5:00 a.m. and 10:00 a.m. on Sunday) 🗓️ The request only goes through if both agreements are honored, so they both have to hold up, bestie 💯
Note that these agreements may be implemented by hand configuration or by evaluating Policy data stored in a Policy database. The point is that there must be a set of known rules in place between entities in order for authorization transactions to be executed 📋
Trust is necessary so each entity can "know" that the policy it is authorizing is correct. This is a business issue as well as a protocol issue, so it's not just a tech thing 🥹 Trust is often set up through third party authentication servers (such as Kerberos), via a certificate authority, by configuring shared secrets or passwords, or by sharing a common facility (such as a connecting wire between processors). These "static" trust relationships are necessary for authorization transactions to take place. Static trust relationships are used in an authorization sequence to set up a "dynamic" relationship between the User and the Service Equipment 🌈 Several possible authorization sequences are possible, and each one uses the static trust "chain" so the user is first approved by the User Home Organization, and then the Service Provider accepts the request based on its trust of the User Home Organization 👑
3. Message Sequences 💌
In general, the User Home Organization and the Service Provider are different entities, or different "administrative domains". In the simplest case, though, the User Home Organization and the Service Provider may be combined into a single entity. This case will be used to describe three authorization sequences possible with the simple case 🍓
In the following sections these concepts get applied to more complicated cases, with separate User Home Organization and Service Provider entities (as in roaming), and with multiple Service Providers that each have their own AAA Servers and Service Equipment (as in distributed services) 🌸
3.1. Single Domain Case 🎯
This case includes the User, the Service Provider's AAA Server, and the Service Provider's Service Equipment. Examples of this case include a NAS supported by a standalone RADIUS server, or a QoS Router supported by a local bandwidth broker 🖥️
The sequences covered in the following figures are the "agent", "pull", and "push" sequences for the single domain case ✨
3.1.1. The Agent Sequence 🕵️♀️
In the agent sequence (see figure 3), the Service Provider AAA Server acts as an agent between the User and the service itself. The AAA Server receives a request from the User and forwards authorization and possibly configuration information to the Service Equipment. In this model, the User sends a request to the Service Provider's AAA Server (1), which applies a policy associated with the User and the particular service being requested. The AAA Server sends a request to the Service Equipment, and the Service Equipment sets up whatever was requested (2). The Service Equipment then responds to the AAA Server, acknowledging that it has set up the Service for the user (3). The AAA Server replies to the User telling it the Service is set up (4) 🎉
Depending on the nature of the service, further communication may happen between the User and the Service Equipment. For this to occur, there needs to be a binding between the User and the authorized service. This requires further study 🤔
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 4 | +-------------------+ |
| User | | | /|\ |
| | | |2 |3 |
| | | \|/ | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 3 -- Agent SequenceExample: A regular user may ask for 1 Mb/s bandwidth (1). The bandwidth broker (AAA Server) tells the router (Service Equipment) to set this user into the 1Mb/s "queue" (2). The router responds that it has done so (3), and the bandwidth broker tells the User the bandwidth is set up (4) 🚀
3.1.2. The Pull Sequence 🪄
The pull sequence (figure 4) is what's typically used in the Dialin application, in the Mobile-IP proposal, and in some QoS proposals 💫 The User sends a request to the Service Equipment (1), which forwards it to the Service Provider's AAA Server (2). The AAA Server evaluates the request and returns an appropriate response to the Service Equipment (3), which sets up the service and tells the User it's ready (4) 🥳
+-------------------------+
+------+ | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| User | | /|\ | |
| | | |2 |3 |
| | | | \|/ |
| | 1 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 4 -- Pull Sequence3.1.3. The Push Sequence ✨
Okay so the push sequence (figure 5) starts with the User grabbing a ticket or certificate from the Service Provider's AAA Server 🎫. That ticket is basically the receipt that says it's o.k. for the User to use the service (1,2) 💅. The User then shows the ticket in its request (3) to the Service Equipment 🦋. The Service Equipment checks the ticket to confirm the Service Provider's AAA Server actually approved the request 🔍. If everything checks out, the Service Equipment sends an o.k. back to the User (4) 🎀.
The ticket the User gets from the Service Provider's AAA Server usually has a time limit on it ⏰. It might also say where the service is located 📍, and in some applications it can be reused for more than one request 🔁.
Here's the main twist: in the push sequence, the AAA Server and the Service Equipment never actually talk to each other directly 🙈. All of that communication gets relayed through the User instead 🫶.
+-------------------------+
+------+ | Service Provider |
| | 1 | +-------------------+ |
| |------+->| AAA Server | |
| |<-----+--| | |
| | 2 | +-------------------+ |
| User | | |
| | | |
| | | |
| | 3 | +-------------------+ |
| |------+->| Service | |
| |<-----+--| Equipment | |
| | 4 | +-------------------+ |
+------+ | |
+-------------------------+
Fig. 5 -- Push Sequence3.2. Roaming -- the User Home Organization is not the Service Provider 🧳
Honestly, this comes up a LOT 💀. The organization that authorizes and authenticates the User is often a different org from the one actually providing the service 👀. This topic was explored in the Roaming Operations (roamops) Working Group 🌍. For this discussion, any situation where the User Home Organization is different from the Service Provider counts as roaming ✈️.
Some examples of roaming: an ISP selling dialin ports to other organizations 📞, or a Mobile-IP provider letting a user from another domain get access 🌸.
The agent, pull and push sequences all work with roaming too 💖. If we group the Service Provider's AAA Server and the Service Equipment together as one logical entity (just to make the description easier), the figures below show what's going on 🧚.
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 4 | +-------------------+ |
| | | |
| | +-------------------------+
| | | /|\
| | |2 |3
| | \|/ |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 6 -- Roaming Agent Sequence
+------+ +-------------------------+
| | | User Home Organization |
| | | +-------------------+ |
| | | | AAA Server | |
| | | | | |
| | | +-------------------+ |
| | | |
| | +-------------------------+
| | /|\ |
| | |2 |3
| | | \|/
| | +-------------------------+
| | | Service Provider |
| User | | +-------------------+ |
| | | | AAA Server | |
| | 1 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 7 -- Roaming Pull Sequence
+------+ +-------------------------+
| | 1 | User Home Organization |
| |----->| +-------------------+ |
| | | | AAA Server | |
| |<-----| | | |
| | 2 | +-------------------+ |
| | | |
| | +-------------------------+
| |
| |
| |
| User | +-------------------------+
| | | Service Provider |
| | | +-------------------+ |
| | | | AAA Server | |
| | 3 | | | |
| |----->| +-------------------+ |
| | | |
| |<-----| +-------------------+ |
| | 4 | | Service | |
| | | | Equipment | |
| | | +-------------------+ |
| | | |
+------+ +-------------------------+
Fig. 8 -- Roaming Push Sequence3.3. Distributed Services 🤝
Sometimes, to give a user a complete service, you need to mix offerings from several service providers 🧩. Like, say a user needs a QoS service for a session that goes across multiple ISPs. Any service that's provided by more than one Service Provider working together in concert is a distributed service 👑. Figure 9 shows what that looks like 🌈.
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| User |======| |======| |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 9 -- Distributed ServicesThe agreements between the entities in figure 9 mean the User's request gets authenticated and authorized by the first organization, and then gets forwarded to the second one 🔁. Heads up: the sequence between the User and Org1 can be different from the sequence between Org1 and Org2 🙃. For example, the first one might use a pull sequence while the second uses an agent sequence 💜. That exact setup is illustrated in figure 10.
+-------------------+ +-------------------+
+------+ | Org1 | | Org2 |
| | | +-------------+ | 3 | +-------------+ |
| | | | AAA Server |--+------+->| AAA Server | |
| | | | |<-+------+--| | |
| | | +-------------+ | 6 | +-------------+ |
| User | | /|\ | | | | /|\ |
| | | |2 |7 | | |4 |5 |
| | | | \|/ | | \|/ | |
| | 1 | +-------------+ | | +-------------+ |
| |------+->| Service | | | | Service | |
| |<-----+--| Equipment | | | | Equipment | |
| | 8 | +-------------+ | | +-------------+ |
+------+ | | | |
+-------------------+ +-------------------+
Fig. 10 -- A Possible Distributed SequenceThere are a bunch of other ways to set up authorization sequences for distributed services too 🧠. For instance, to cut down on delay when setting up a session, Org1 could send a response to the user before it hears back that Org2 has authorized the service ⚡. But if that happens, Org1 would need to be able to revoke the authorization it already sent 😭, in case Org2 doesn't send its authorization within some amount of time ⏳. Yikes, but make it work 💅✨
3.4. Combining Roaming and Distributed Services 💅
okay so figure 11 is where roaming and distributed services get together and have a whole moment 🫶 the way contract and trust relationships can get set up in a bunch of different ways depends on lots of stuff, especially the business model. no cap, it's giving flexibility.
+------+ +-------------------+ +-------------------+
| | | User Home Org | | SuperOrg |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | +-------------------+ +-------------------+
| |
| |
| | +-------------------+ +-------------------+
| User | | Org1 | | Org2 |
| | | +-------------+ | | +-------------+ |
| | | | AAA Server | | | | AAA Server | |
| | | | | | | | | |
| | | +-------------+ | | +-------------+ |
| | | | | |
| | | +-------------+ | | +-------------+ |
| | | | Service | | | | Service | |
| | | | Equipment | | | | Equipment | |
| | | +-------------+ | | +-------------+ |
| | | | | |
+------+ +-------------------+ +-------------------+Fig. 11 -- Roaming and Distributed Services
New entities that combine or add capabilities can be created to meet business needs, bestie 💖 in figure 11 we get to see one of those possibilities, a SuperOrg entity 🦋 the vibe is that this entity would provide authentication and authorization for organizations that are providing services to end-users. it could be considered to be a wholesaler or broker. while not all authorization will require having a broker, authorization protocols should allow such entities to be created to meet legitimate requirements. main character energy for the protocol design 👑
Having considered the basic players and how they interact, we will now consider different ways that authorization data may be stored in the network. ✨
4. Relationship of Authorization and Policy ✨
The Policy Framework (policy) Working Group is seeking to provide a framework to represent, manage, and share policies and policy information in a vendor-independent, interoperable, scalable manner. [5],[6],[7]. this section explores the relationship of policy and authorization and sets the stage for defining protocol requirements for supporting policy when included as part of multi-domain authorization. the work presented here builds on the policy framework, extending it to support policy across multiple domains. it's giving foundation 🧚
One view of an authorization is that it is the result of evaluating policies of each organization that has an interest in the authorization decision. in this document the assumption is that each administration may have policies which may be indexed by user, by service, or by other attributes of the request. the policies of each administration are defined independently of other administrations. 🌸
Each independent policy must be 1) retrieved, 2) evaluated, and 3) enforced. three steps, no skipping, periodt 💅
4.1. Policy Retrieval
Policy definitions are maintained and stored in a policy repository [5] by (or on behalf of) the organization that requires them. the Policy Framework WG is working on a way to describe policy [7]. other implementations describe policy as a set of ACL lists. Policy definitions must be retrieved in order to be evaluated and enforced. Policy Definitions can be indexed by requester, by service attribute, or by some other key. the organization requiring the policy is also responsible for determining which policy is to be applied to a specific authorization request. 🎀
Policy retrieval is typically done by the administration that defines the policy or by an agent acting for that administration. so like, a policy defining the times of day that a particular User is allowed to connect to the network is maintained and retrieved by the User Organization. a policy defining a time that ports will be unusable because of maintenance is maintained and retrieved by the Service Provider. 🍓
Note that some implementation may choose to have the Service Provider retrieve a policy from the User Home Organization using a distributed directory access protocol. this may be appropriate in some cases, but is not a general solution. to understand why, suppose the remote administration and the home administration communicate via a broker which proxies their communications. in this case the remote and home administrations have no prior relationship, and therefore the home administration directory is unlikely to be open for access by the remote administration and vice versa. not me overthinking the broker situation 🙈
4.2. Policy Evaluation
Evaluation of policy requires access to information referenced by the policy. often the information required is not available in the administration where the policy is retrieved. for example, checking that a user is allowed to login at the current time can readily be done by the User Home Organization because the User Home Organization has access to current time. but authorizing a user requiring a 2Mb/s path with less than 4 hops requires information available at a Service Provider and not directly available to the UHO, so the UHO must either 1) have a way to query a remote administration for the needed information or 2) forward the policy to the remote administration and have the remote administration do the actual evaluation or 3) attempt somehow to "shadow" the authoritative source of the information (e.g by having the Service Provider send updates to the UHO). ngl the options are a lot but each one has its own energy 💜
Applications might support either 1) or 2), and a general authorization protocol must allow both. case 3) is not considered further as shadowing seems too "expensive" to be supported by an AAA protocol. 💀
An example of case 1 is when a Service Provider forwards a request to a UHO which includes a query for the clearance code of the User. the Service Provider policy includes reference to the clearance code and the information in the reply is used as input to that policy. ✨
An example of case 2 is when the UHO approves an authorization conditional on the Service Provider confirming that there is currently a specific resource available for its use. the UHO includes the "policy" along with a conditional authorization to the Service Provider. 🦋
4.3. Policy Enforcement
Policy Enforcement is typically done by the Service Provider on the Service Equipment. the Service Equipment is equivalent to the Policy Target described in the Policy Framework [5]. so a NAS may enforce destination IP address limits via "filters" and a Router may enforce QoS restrictions on incoming packets. the protocol that sends the information between the Service Equipment and the Service Provider AAA Server may be specific to the Service Equipment, but it seems that the requirements are not different in kind from what is required between other AAA servers. 🔥
In particular, an AAA Server could send a "policy" to the Service Equipment stating what the equipment should do under various situations. the Service equipment should either set up to "enforce" the policy or reject the request. 👑
The AAA Server could also send a query to the Service Equipment for information it requires to evaluate a policy. 🫶
4.4. Distributed Policy
A policy is retrieved by a Policy Retrieval Point (PRP) from a Policy Repository, evaluated at a Policy Decision Point (PDP) or Policy Consumer, and enforced at a Policy Enforcement Point (PEP) or Policy Target [5]. the acronyms are a lot but we are literally going to get through this together 🌈
Generally, any of the AAA Servers involved in an authorization transaction may retrieve a policy or evaluate a policy, and any of the Service Equipment may enforce a policy. Policy Repositories may reside on any of the AAA Servers or be located elsewhere in the network. 🧚
Information against which policy conditions are evaluated (such as resource status, session state, or time of day) are accessible at Policy Information Points (PIPs) and might be accessed using Policy Information Blocks (PIBs). an interesting question in any authorization application that uses policy is where are the PDPs, PRPs, PIPs and PEPs? 🤔
Figure 12 shows which policy elements may be available at different points in the model. in distributed services, there may be multiple Service Providers involved in the authorization transaction, and each may act as the policy elements shown below. 🎀
Note that the User (or requester) may also be a PRP (e.g. use policy description to specify what service is being requested), a PIP (have information needed by other entities to evaluate their policy), and a PDP (decide if it will accept a service with specific parameters). the user is lowkey a whole multitasker 💅
+------+ +------------------------------+
| | | User Home Organization |
| | | +-------------------+ PRP |
| | | | AAA Server | PIP |
| | | | | PDP |
| | | +-------------------+ |
| | | |
| | +------------------------------+
| |
| |
| | +------------------------------+
| User | | Service Provider |
| | | +-------------------+ PRP |
| PRP | | | AAA Server | PIP |
| PIP | | | | PDP |
| PDP | | +-------------------+ |
| | | |
| | | +-------------------+ |
| | | | Service | PIP |
| | | | Equipment | PEP |
| | | +-------------------+ |
| | | |
+------+ +------------------------------+
PRP = Policy Retrieval Point
PIP = Policy Information Point
PDP = Policy Decision Point
PEP = Policy Enforcement PointFig. 12 -- Where Different Policy Elements May be Located
An AAA protocol must be able to transport both policy definitions and the information needed to evaluate policies. it must also support queries for policy information. the requirements are clear, and the protocol has to deliver 🫶🔥
5. Use of Attribute Certificates to Store Authorization Data 🦋
okay so this section is about another way to safely carry the attributes an authorization decision is based on 💅 The PKIX Working Group is working on X.509 Attribute Certificates [8], and this proposal is mostly built on that work 🫶
when you're doing certificate-based authorization, you're usually less interested in who the entity is and more interested in other stuff, like roles, account limits, etc. Those are the things that should actually drive the decision 👑
in lots of cases it's better to keep this info separate from identity, for management, security, interoperability, or other reasons 🎀 But this authorization info may still need protection, kind of like a public key certificate does. The name for that structure is an Attribute Certificate (AC), which is a digitally signed (certified) set of attributes ✨
an AC is basically an X.509 public key certificate [9] with one main difference: it has no public key 🙈 It typically contains group membership, role, clearance, and other access control info tied to the AC owner. The X.509 standard also defines a syntax for ACs 💖
when an access decision is made based on an AC, the access decision function (in a PEP, PDP, or somewhere else) may need to make sure the AC owner is the one who actually requested access 👀 The link between the request and the AC can be made if the AC has a "pointer" to a Public Key Certificate (PKC) for the requester, and that PKC was used to authenticate the request. Other kinds of linkage can be defined for other authentication schemes 🌸
people get PKCs and ACs mixed up all the time, so here's an analogy that helps 🧚 A PKC is like a passport: it identifies the owner, it's valid for a long time, it's hard to forge, and it goes through a strong process to establish the owner's identity. An AC is more like an entry visa 🛂 It's usually issued by a different authority than the passport office, and it doesn't last as long as a passport. Getting an entry visa usually means showing a passport that proves who you are, which is why getting the visa is a simpler process. The visa also refers to the passport as part of how it spells out the terms under which the passport owner is allowed to enter a country 🌈
together with authentication services, ACs give you a way to securely transport authorization info to applications 🔥 There are a bunch of different paths an AC can take, though 🦋
in some environments it makes sense for a client to "push" an AC to a server. This means no new connections between the client and server domains are needed. It also means servers don't have to do any searching, which helps performance 🚀
in other cases it's better for the client to just authenticate to the server, and then the server asks the client's AC issuer or a repository for the AC. The big win here is that this model can be done without changing the client or the client/server protocol 🙌 It's also a better fit for some inter-domain cases where the client's rights should be assigned within the server's domain, not the client's "home" domain 🏠
there are a number of exchanges that could happen, and three entities are involved: client, server, and AC issuer 💜 A directory service can also be supported as a repository for AC retrieval 🗂️
Figure 13 gives an abstract view of the exchanges that might involve ACs. Heads up: the lines in the diagram represent protocols that must be defined, not data flows 🙈 The PKIX working group will define the required acquisition protocols. One candidate for the lookup protocols is LDAP (once there's an LDAP schema that says where an AC can be found) 💅
+--------------+ +---------------+
| AAA Server/ | | |
| AC Issuer +----+ | Directory |
| | | | |
+--+-----------+ | Server +-------+-------+
| | Acquisition |
|Client | |Server
|Acquisition +----------------------+ |Lookup
| | |
+--+-----------+ +--+----+-------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol | AAA Server |
+--+-----------+ +---------------+
|
| Client Lookup
+--+-----------+
| |
| Directory |
| |
+--------------+
Fig. 13 -- AC ExchangesFigure 14 shows the data flows for one particular case, the "push" one we talked about earlier (section 2.1.3) ✨
+--------------+
| AAA Server/ |
| AC Issuer |
| |
+--+-----------+
|
|Client
|Acquisition (1)
|
+--+-----------+ +---------------+
| | AC in application | Service |
| User +------------------------+ Equipment/ |
| | protocol (2) | AAA Server |
+--------------+ +---------------+
Fig. 14 -- One example of an AC exchangeso in the diagram, the user first contacts the AC Issuer, then puts the AC into the application protocol 🎀 The Service Equipment then has to validate the AC and use it as the basis for the access decision (this job can be split between a PEP and a PDP) 🫶
6. Resource Management ✨
authorization requests can get chained through a set of servers, like we covered in earlier sections 🔗 Each server might have a contractual relationship with the servers on either side of it in the chain 🤝 For a lot of the applications being looked at, authorization ends up setting up an ongoing service, which we call a session 🎬 Every server involved in the authorization might also want to keep track of the session's state, and be able to make changes to it if needed 👀 To keep this simple to talk about, we assume each AAA Server MAY have a Resource Manager component 💖 Resource Managers tracking the same session need to be able to start changes to the session, and to tell other Resource Managers when changes happen. Communication between Resource Managers creates requirements for an authorization protocol 🔥
an example: a user sets up a QoS path through two ISPs. While that path is active, one of the ISPs gets a request for more bandwidth from a higher priority user 😭 The ISP may need to take some bandwidth from the lower priority user's previously allocated session and give it to the new request 💀 To make that work, every administration in the authorization path has to be informed and agree to the change (you could think of this as "authorizing the new value") 🌸
6.1. Session Management and State Synchronization 💅
when an AAA Server grants authorization for some resource to an AAA requester (either a User or another AAA Server), the server may need to keep session state info 🧠 That state is used to make decisions about new sessions based on the state of current ones, and it lets all interested AAA Servers monitor sessions 👑
each session is identified by a session identifier, which must be unique within each AAA Server 🦋 Communication between AAA Servers must include the session identifier. It's desirable for the session identifier to be the same across all AAA servers, because otherwise each server has to map other servers' identifiers to its own 🙈 A single session identifier makes auditing and session control way simpler ✨
keeping session state across AAA administrative boundaries makes things way more complicated, especially if every AAA Server in the trust chain has to keep state too 😵 This can be seen as an interdomain database replication problem. The protocol must include tools to help manage replicated state. Some of the problems to be addressed are:
a) Service Equipment must be able to notify its Resource Manager when a session terminates or changes state in some other way. The Resource Manager must inform other Resource Managers that keep state for this session 📣
b) The Resource Manager will need to set a time limit for each session. That limit has to be refreshed either by having the Resource Manager query for authoritative status, or by having the authoritative source send periodic keep alive messages that get forwarded to all Resource Managers in the authorization chain ⏰ Figuring out the right session lifetime may depend on the application and on how much risk is acceptable 🎯 If the service is billed by time, the lifetime may need to be relatively small. If it's billed on usage, the lifetime may be relatively large 💸
c) Any Resource Manager in the chain must be able to terminate a session. This means the Resource Manager has to know about at least the adjacent AAA Servers in the authorization chain 🔗
here's an example of how resource management can be used: the PPP dialin application 📞 A home ISP may want to restrict how many concurrent sessions a user can have at once. This matters a lot when providers offer all-you-can-eat Internet access 🍓 The fraud potential is huge, since a user could hand their username/password to a bunch of people, which costs the ISP revenue 😤 Resource management lets the home ISP AAA server spot when a user is active, and reject any authorization request for that user until a termination indication comes in from the NAS or the session expires 🛑
6.2. The Resource Manager 💅
Okay bestie, this is the Resource Manager, and it is giving main character energy 👑 Let's go through what it actually does ✨
This section goes into more detail on the functions of the Resource Manager. It's the component that tracks the state of sessions for an AAA Server or Service Equipment 🧚 It also may allocate resources to a session (like IP addresses 🌸), and it may track use of resources that peer resource managers allocated to a session (like bandwidth in a foreign administrative domain 🦋). It also gives the User interfaces to acquire or release authorized sessions 🎀
The Resource Manager keeps all the session-specific AAA state information the AAA Server needs 🗂️ That state can include pointers to peer Resource Managers in other administrative domains that hold extra AAA state about the same session. So the Resource Manager is the anchor point in the AAA Server where a session can be controlled, monitored, and coordinated 🎯 even if that session is using network resources or services across several Service Provider administrative domains 🌈
The Resource Manager has several important functions:
a) It lets Service Provider operations staff inspect the status of any allocated resources and services, including resources that span foreign Service Provider administrative boundaries 🔍 The peer Resource Managers will cooperatively share only the state information subset that is required to help diagnose cross-domain trouble tickets. The network operator may also modify or completely cancel one of the User's active authorizations 🙅♀️
b) It's the process other Resource Managers contact to tell the AAA Server that a specific session has been cancelled 📣 That info then gets relayed to the other peer Resource Managers that also know about that session, so they hence must cancel it too 💀
c) The Resource Manager hides the identity and location of its private internal AAA components from other administrative domains and from the User 🙈 while still making it easy for those domains to cooperate 🫶
d) The Resource Manager works with "policy servers," aka Policy Decision Points (PDPs) 🧠 It maintains internal state information, possibly complex cross-administrative domain information, backed up by dialogues with its peer Resource Managers. A policy server can use that state information when evaluating a particular policy ✨
e) Splitting the Resource Manager and the policy server into two separate architectural components is what lets a single session span multiple administrative domains 🦋 Each administrative domain has one or more policy servers cooperating with its Resource Manager, and honestly that's so iconic 😭
AAA resource managers will normally use the same trust relationships needed for authorization sequences 🤝 It's possible to set up independent relationships, but that is discouraged 🙅♀️
7. AAA Message Forwarding and Delivery 🚚
Okay so an AAA Server is responsible for securely forwarding AAA messages to the correct destination system or process in the AAA infrastructure 📬 Two well-known examples are forwarding AAA messages for a roaming AAA service and forwarding them for a distributed AAA service 🌍 The same principle can also be applied to intra-domain communications. Message forwarding happens in one of two modes 💖
The first mode is when an AAA server needs to forward a message to a peer AAA server that has a known "logical destination address." That address has to be resolved by an application-specific procedure into its actual network address 🔎 Usually the forwarding procedure looks up a database using an application-specific identifier to find the peer's network address. For example, in the roaming dialin application, that identifier may be an NAI 🪪 A bandwidth brokerage application would use other search indices unique to its problem domain to select the addressed peer AAA server 📊 Once the address resolution procedure has completed successfully, the AAA server transmits the message to its peer over the connection associated with that destination network address 🚀
The second mode is when the AAA server already has an established session representing an authorization 💅 The session's state contains the addressing and context used to direct the message to its destination, whether that's a peer AAA server, PDP, PEP, or User 🎯 The message is sent over the AAA server's connection to that destination peer, multiplexed with other sessions' messages 🧵 The message must be qualified by a session identifier that is understood by both end points 🆔 The AAA message's destination may be either intra-administrative domain or inter-administrative domain. In the former case, the destination process may reside on the same system as the AAA server 🖥️
On top of all that message forwarding, the underlying message delivery service must meet the following requirements 📋
- Unicast capability -- An end system can send a message to any other end system with minimal latency of session setup/disconnect overhead messages, and no end system overhead of keeping state information about every potential peer ☝️
- Data integrity and error detection -- This data transport protocol assumes an underlying datagram network layer service that includes packet discard on error detection, and data integrity protection against third party modifications 🛡️
- Reliable data transport assurance -- When an end system successfully receives a message marked receipt requested, it must acknowledge that message to the sending system, either by piggybacking the acknowledgement on an application-specific reply message or else as a standalone acknowledgement message 📨 The sending system maintains a retry timer. When the timer expires, the sending system retransmits a copy of its original message. It gives up after a configurable number of unsuccessful retries 🔁
- Sequenced data delivery -- If multiple messages are sent between a pair of end systems, those messages are delivered to the addressed application in the same order they were transmitted 📚 Duplicates are silently suppressed 🤫
- Responsive to network congestion feedback -- When the network enters into congestion, the end systems must detect that condition, and they must back off their transmission rate until the congestion subsides 🐢 The back off and recovery algorithms must avoid oscillations 🌊
8. End-to-End Security 🔐
When AAA servers communicate through intermediate AAA servers, such as brokers, it may be necessary for a part of the payload to be secure between the originator and the target AAA server 🫣 The security requirement may consist of one or more of the following: end-to-end message integrity, confidentiality, replay protection, and nonrepudiation 🔒 Furthermore, it is a requirement that intermediate AAA servers be able to append information, such as local policy, to a message before forwarding it to its intended destination 📎 It may also be required that an intermediate AAA Server sign that appended information ✍️
This requirement has been clearly documented in [10], which describes many current weaknesses of the RADIUS protocol [11] in roaming networks, since RADIUS does not provide such functionality 🚨 One well-known attack is the ability for intermediate nodes to modify critical accounting information, such as session time 😱 Yikes, that is not it 😤
Most popular security protocols (e.g. IPSec, SSL, etc.) do not provide the ability to secure a portion of the payload 🙃 Therefore, it may be necessary for the AAA protocol to implement its own security extensions to provide end-to-end security 🛠️
9. Streamlined Authorization Process ⚡
The techniques described above allow for great flexibility in distributing the components required for authentication and authorization 🧩 However, working groups such as Roamops and MobileIP have identified requirements to minimize Internet traversals in order to reduce latency 🏎️ To support these requirements, data fields necessary for both authentication and authorization SHOULD be able to be carried in a single message set 💨 This is especially important when there are intermediate servers (such as Brokers) in the AAA chain 🔗
It should also be possible for the Brokers to allow end-to-end (direct) authentication and authorization ✨ Here's how it can work: the User Home Organization generates a ticket, which is signed using the UHO's private key 🎫 The ticket is carried in the accounting messages. The accounting messages must flow through the Broker, since the Broker is acting as the settlement agent and requires this information 💸 Some Brokers will need to be in the authentication and authorization path as well, since they use this information to detect fraudulent activity 🕵️ So the above should be optional 🌸
For end-to-end authentication and authorization to occur, the Broker may need to act as a certificate authority 📜 All members of the roaming consortium would be able to trust each other (to an extent) using the certificates 🤝 A Service Provider's AAA server that sends a request to the Broker should be able to receive a redirect message that lets the two peers (Service Provider and UHO) interact directly 💞 The redirect message from the Broker should include the UHO's certificate, which means the Service Provider doesn't have to access the certificate archive 🙌 The request from the Service Provider could include its own certificate, plus a token from the Broker's redirect message that is timestamped and guarantees the Service Provider is in good standing with the Broker ⏱️ This also means the home domain doesn't have to access the Certificate Revocation List (CRL) 🧾
10. Summary of the Authorization Framework 🎀
Okay recap time 💜 The above introduced the basic players in an authorization transaction: the User, the User Home Organization, the Service Provider's AAA Server, and the Service Equipment 🧑🤝🧑 It discussed relationships between entities based on agreements or contracts, and on "trust." Examples of authorization sequences were given 📝
We briefly described the concepts of roaming and distributed services 🌐 We also considered combining roaming and distributed services, which introduced the concept of a "wholesaler" or Broker 🛍️ We looked at using policies and attribute certificates to store and transmit authorization data 📦 We discussed managing the resources to which access has been authorized, including tracking state information for session-oriented services, and we defined the Resource Manager component of an AAA Server 🗃️ We considered forwarding AAA messages among servers in possibly different administrative domains 📮 We considered the need for end-to-end security of portions of the payload of authorization messages that pass through intermediate AAA Servers 🔐 Finally, we stressed the need for a streamlined authorization process that minimizes delay for latency-sensitive applications 🏃♀️💨
The intent is that this will support discussing and understanding the requirements of specific applications that need authorization services 🦋✨
11. Security Considerations 🔐💅
Okay bestie, this section is SO important. Authorization is literally a security mechanism itself, so if an authorization protocol can be easily abused to get around the protection it's supposed to provide, that's a total disaster 😭🚨. It is the job of protocol designers to make their protocols resilient against well-known types of attacks 🛡️✨. Here are some things that can help guide designers while they're building authorization protocols 🧠💜.
Authorization protocols MUST NOT be susceptible to replay attacks 🙅♀️🔁. Like, if authentication data is carried along with the authorization data, the authentication protocol being used has to either be totally impervious to replay, OR the confidentiality of that authentication data has to be protected 🔒🥺. No shortcuts, periodt 💀.
If proxying is required, the authorization protocol MUST NOT be susceptible to man-in-the-middle attacks 👀🕵️♀️. Not even a little bit 🙅♀️💅.
If the push model is used, the confidentiality of the authorization data MUST be ensured so that it can't be hijacked by third parties and used to obtain a service fraudulently 😤🚫. Nobody should be sneaking in and stealing access like that 🦹♀️❌.
If the agent model is used, the binding between the authorization and the service itself MUST be protected 🔗🛡️. This stops service that was authorized for one party from being fraudulently received by another party 🙈🚫. Main character energy means nobody else gets to use your ticket 🎟️💖.
Okay so, on top of guarding against circumvention, authorization protocols designed using this framework are going to have some intrinsic security requirements of their own 📋✨. These are included among the requirements in [2] and I'll summarize them briefly below 🌸.
One of the intrinsic security needs is that authorization protocols may carry sensitive information 🫣💜. It's super necessary to protect that information from disclosure to unauthorized parties 🙅♀️🔐. This includes (as discussed in section 8) even certain parties who are involved in the authorization decision itself 👀😬. Yes, even them 💀.
We've talked about using multi-party trust chains that involve relaying authorization data through brokers or other parties 🔗🦋. In those cases, the integrity of the chain MUST be maintained 🫶🔥. It may be necessary to protect the data exchanged between parties using things like encryption and digital signatures 🔏🌈.
Finally, because authorization is going to be necessary to get access to lots of Internet services, a denial of service attack against an authorization server can be just as effective as a denial of service attack against the service equipment itself 😭💀. Either way, people are locked out of the Internet services they need 🚫🌐. Not cute 😤.
Glossary 📖🎀
Attribute Certificate
Structure containing authorization attributes which is 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 which is 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 🗝️🙈. [12]
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] 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. 📗
[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] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑
[5] Stevens, M., "Policy Framework", Work in Progress. 🚧
[6] Strassner, John, Ed Ellesson, and Bob Moore, "Policy Core Information Model -- Version 1 Specification", Work in Progress. 🚧
[7] Strassner, John, et al, "Policy Framework LDAP Core Schema", Work in Progress. 🚧
[8] Farrell, Stephen and Russell Housley, "An Internet Attribute Certificate Profile for Authorization", Work in Progress. 🚧
[9] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure -- Certificate and CRL Profile", RFC 2459, January 1999. 🪪
[10] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999. 🧳
[11] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997. 📞
[12] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. 📱
[13] Yavatkar, R., Pendarakis, D. and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. 🚦
Authors' Addresses 📮💌
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 Mail: 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.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: rfc2904 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms