RFC 2906
AAA Authorization Requirements
RFC 2906: AAA Authorization Requirements 🦋
okay bestie, this is RFC 2906, "AAA Authorization Requirements," from the Network Working Group ✨
- Request for Comments: 2906 🌸
- Category: Informational. It's not a standard, just info for the community 📚
- Date: August 2000 🎀
- Authors: S. Farrell (Baltimore Technologies), J. Vollbrecht (Interlink Networks, Inc.), P. Calhoun (Sun Microsystems, Inc.), 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.) 👑
- Obsoletes / Updates: the title block doesn't list anything this one obsoletes or updates 🙈
Status of this Memo 💅
This memo gives info to the Internet community. It is NOT a specification of any Internet standard, obviously 😭 Distribution is unlimited, so share it with everyone 🌈
Copyright Notice 🔥
Copyright (C) The Internet Society (2000). All Rights Reserved. 💜
Abstract 🧚
okay so this doc lays out what Authentication Authorization Accounting (AAA) protocols need to do in order to support authorization services on the Internet. The requirements came from studying a bunch of applications, including mobile-IP, roamops, and others 👀
Table Of Contents 🍓
1. Introduction.................................................2
2. Requirements.................................................3
2.1 Authorization Information..............................3
2.2 Security of authorization information..................7
2.3 Time...................................................9
2.4 Topology..............................................10
2.5 Application Proxying..................................12
2.6 Trust Model...........................................12
2.7 Not just transactions.................................14
2.8 Administration........................................15
2.9 Bytes on-the-wire.....................................16
2.10 Interfaces............................................17
2.11 Negotiation...........................................18
3. Security Considerations.....................................19
4. References..................................................20
Authors' Addresses.............................................20
Full Copyright Statement.......................................231. Introduction ✨
so this doc is one of three docs the AAAarch RG is looking at for AAA authorization requirements. The trio is:
AAA Authorization Framework [FRMW]
AAA Authorization Requirements (this document)
AAA Authorization Application Examples [SAMP]the work started in the Authorization subgroup of the AAA Working Group. Once that WG's charter shifted to focus on MobileIP and NAS requirements, the AAAarch Research Group got chartered inside the IRTF to keep going with the architecture work. This memo is one of four the subgroup made 🦋 It's a starting point for the AAAarch RG, and it's still a work in progress. It's published so people in this area can actually use it. It is NOT a final word on architecture or requirements, so don't treat it like one 🙈
the process was to analyze the requirements from [SAMP] using a shared understanding of the AAA authorization framework [FRMW]. You'll want to know the general authorization stuff already, and reading [FRMW] helps a lot because that's where the term definitions live 📚
the key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in [RFC2119]. 🔑
2. Requirements 💖
requirements are grouped under headings just for convenience. The grouping doesn't mean anything 💅
technical terms are defined and explained in [FRMW], so check there if something's confusing 🧚
each requirement is a short statement, usually a sentence or two. Most of them come with a paragraph of explanation, and sometimes that includes an example. Full examples are in [SAMP] ✨
heads up, the requirements aren't "orthogonal." Some of them repeat or overlap with each other, and that's intentional 😭
2.1 Authorization Information 🎀
2.1.1 🎀 Basing decisions on information
authorization decisions MUST be able to be based on info about the requestor, the service or method requested, and the operating environment (authorization information). AAA protocols are required to carry this info 👑
this is basically saying a protocol needs an access decision function. That function takes inputs based on who's asking, what they want, and the environment around it 🌸
2.1.2 🎀 Representing it as attributes
it MUST be possible to represent authorization information as sets of attributes. It MAY be possible to represent it as objects too 🦋
this means authorization info has to be breakable down into sets of attributes. It doesn't imply any particular way to represent those attributes 💜
2.1.3 🎀 Packing multiple services in one message
it MUST be possible to package authorization information so that the info for multiple services or applications can ride in a single message in an AAA or application protocol 🚀
a protocol that always needed separate AAA messages or transactions for each service or application would NOT meet this. Like, a single AAA message or transaction should be enough to allow both network and application access, so it's giving efficiency 💅
2.1.4 🎀 Standard attribute types
standard attribute types SHOULD be defined when they're relevant to lots of Internet applications and services. Think identity information, group information, and so on 🍓
there are a ton of attributes that show up in loads of contexts, and they should only get defined once. That keeps things interoperable and stops everyone from duplicating work 🫶
2.1.5 🎀 Not just identity
authorization decisions MUST NOT be limited to identity information. AAA protocols MUST support the use of non-identifying information, like for role based access control (RBAC) 🔥
access can be based on clearances, roles, groups, or other info, and that's required. A AAA protocol that only carried identity info would not meet the requirement, periodt 💀
2.1.6 🎀 Limits as well as attributes
authorization data MAY include limits in addition to attributes that are directly "owned" by end entities 🌈
some attributes aren't just a thing an entity has. Take a spending limit of IR 1,000, which isn't an intrinsic attribute of an entity. This also changes the access decision function, because the comparison isn't a simple equality match anymore ✨
2.1.7 🎀 Attribute types from non-AAA protocols
it MUST be possible for other (non-AAA) protocols to define their own attribute types. Those types can then be carried inside an authorization package in an AAA or application protocol 🧚
the attributes that matter for an authorization decision can depend on the application protocol. For example, lots of attribute types are defined by [RFC2138], and support for those semantics is required. Only AAA entities that know about the added attribute types can actually use them, though 🙈
2.1.8 🎀 Admin-defined attribute types
it SHOULD be possible for administrators of deployed systems to define their own attribute types. Those can be carried inside an authorization package in an AAA or application protocol 🫶
the attributes that matter can depend on a closed environment. Lots of organizations have a clear seniority scheme that decides access levels, for instance. And again, only AAA entities that are aware of the added types can make use of them 💅
2.1.9 🎀 No central control of the attribute namespace
it SHOULD be possible to define new attribute types without central administration and control of the attribute name space 🦋
some kind of registration, centralized or distributed, is needed if you want to avoid collisions in attribute type allocations. BUT a AAA protocol that always requires that central registration would not meet this requirement. Collisions should still be avoided where possible 💜
2.1.10 🎀 Multiple values per attribute
it MUST be possible to define attribute types so that one instance of an attribute in a single AAA message can have multiple values 👑
a protocol that doesn't let an attribute show up more than once in a message or transaction would not meet this. For example, it should be possible to have a "group" attribute holding more than one groupname (or number, or whatever) 🌸
2.1.11 🎀 Telling instances apart by security domain or authority
it MUST be possible to distinguish different instances of the same authorization attribute type or value, based on "security domain" or "authority" 🔥
this recognizes that attributes can't be told apart by their value alone. For example, every NT domain (they all use the English language) has an Administrators group. The access decision function has to be able to work out which of those groups the requestor belongs to 🎀
2.1.12 🎀 Updating the authorization rules
AAA protocols MUST specify mechanisms for updating the rules that control authorization decisions 🚀
a AAA protocol that can't provide a way to distribute authorization rules isn't enough. As an example, this could be used to download ACLs to a PDP 🧚
the mechanism doesn't have to be the one used every time. Storing authorization rules in a trusted repository (often an LDAP server) will often be used instead of this AAA protocol mechanism. This requirement also doesn't ask for a standardized format for the rules. It only asks that there be a way to transport them 💅
2.1.13 🎀 Chains of AAA entities
the AAA protocol MUST allow for chains of AAA entities to be involved in an authorization decision 🌈
this means more than one AAA server may have to take part in a single authorization decision. That can happen because the decision spans more than one "domain," or because authorization needs to be spread out within a single "domain" 🫶
2.1.14 The AAA protocol MUST allow for intermediate AAA entities to add their own local authorization information to a AAA request or response.
Okay so this one is giving "passing the group project around and everyone gets to add their part" 📝✨ Where more than one AAA entity is involved in an authorization decision, each of them is allowed to touch the AAA messages, either by adding more info or by processing parts of the info that's already there 💅
2.1.15 AAA entities MAY be either be deployed independently or integrated with application entities.
Lowkey the vibe here is flexibility 🦋 The AAA entities may be set up as AAA servers, or they may be built right into application entities. Your choice, bestie 🫶
2.1.16 The AAA protocol MUST support the creation and encoding of rules that are to be active inside one AAA server based on attributes published by another AAA server. The level of authorization of the requesting AAA Server MAY govern the view on attributes.
Okay this one is so real 😭 One AAA entity might need to hand out authorization rules to another one, and the one that gets the rules might only be seeing part of the full story 🧚 Main character energy for the partial view tbh 👀
2.1.17 AAA protocols MAY have to support the idea of critical and non- critical attribute types.
This is basically the same energy as the criticality flag in public key certificate extensions 🌸 Some attributes are must-know, some are nice-to-know 💖
2.1.18 A AAA protocol MUST allow authorization rules to be expressed in terms of combinations of other authorization rules which have been evaluated.
Ex: access may only be granted if the requestor is a member of the backup users group and NOT a member of the administrator's group. Ngl this is so iconic 🙈 The requirement doesn't say which kinds of combinations have to be supported though, so that part is open 🎀
2.1.19 It SHOULD be possible to make authorization decisions based on the geographic location of a requestor, service or AAA entity.
This is just one example of an authorization attribute type, and it's notable because it needs different underlying implementation mechanisms 🌍✨
2.1.20 It SHOULD be possible to make authorization decisions based on the identity or the equipment used by a requestor, service or AAA entity.
Another example attribute type 💜 It's notable because it may need different underlying implementation mechanisms (if IPSec isn't available) 🔐
2.1.21 When there are multiple instances of a given attribute, there must be an unambiguous mechanism by which a receiving peer can determine the value of specified instance.
So if one attribute shows up more than once, the receiving peer needs a clear way to figure out which value it's looking at 🍓 No mix-ups allowed, periodt 💅
2.2 Security of authorization information
2.2.1 It MUST be possible for authorization information to be communicated securely in AAA and application protocols. Mechanisms that preserve authenticity, integrity and privacy for this information MUST be specified.
Okay the security section is where things get serious 🔥 This says there has to be a well-defined way to secure authorization info, but not that those methods must always be used. Whether support is required for conformance is left open 🤷♀️ The big thing is that there must be mechanisms so a service administrator sitting in the middle of a chain can't read or change the authorization info being sent between other AAA entities 😤
2.2.2 AAA protocols MUST allow for use of an appropriate level of security for authorization information. AAA protocols MUST be able to support both highly secure and less secure mechanisms for data integrity/confidentiality etc.
Not every chat needs a bodyguard 💅 AAA protocols shouldn't force a heavy security overhead, so the security mechanisms don't always have to be used, though skipping them may affect the authorization decision 🎀
2.2.3 The security requirements MAY differ between different parts of a package of authorization information.
Some parts may need confidentiality and integrity, and some may only need integrity 🌈 This basically means we want something like selective field security. For example, info needed to get onto a network may have to be in the clear, while info needed for access to an application inside that network may have to be encrypted in the AAA protocol 🔒
2.2.4 AAA protocols MUST provide mechanisms that prevent intermediate administrators breaching security.
This is a basic requirement to stop man-in-the-middle attacks, like an intermediate administrator changing AAA messages on the fly 😱 Absolutely not 🙅♀️
2.2.5 AAA protocols MUST NOT open up replay attacks based on replay of the authorization information.
For example, an AAA protocol shouldn't allow flooding attacks where the attacker replays AAA messages that make the recipient use a lot of CPU or communications before the replay gets detected 💀 Nope nope nope 🚫
2.2.6 AAA protocols MUST be capable of leveraging any underlying peer entity authentication mechanisms that may have been applied - this MAY provide additional assurance that the owner of the authorization information is the same as the authenticated entity. For example, if IPSec provides sufficient authentication, then it must be possible to omit AAA protocol authentication.
So if the layer underneath already authenticates the peer, the AAA protocol should be able to use that 🫶 Ex: if IPSec gives enough authentication, then it has to be possible to skip AAA protocol authentication. It can also give extra assurance that the owner of the authorization info is the authenticated entity ✨
2.2.7 End-to-end confidentiality, integrity, peer-entity- authentication, or non-repudiation MAY be required for packages of authorization information.
This says confidentiality (or the other security services) may have to be provided for parts of an AAA message, even when it's sent through other AAA entities 🕵️♀️ It also allows that such a message can contain parts that aren't confidential, or that don't need the other services. Plus, intermediate AAA entities may themselves be endpoints for end-to-end security applied to other parts of the message 💖
2.2.8 AAA protocols MUST be usable even in environments where no peer entity authentication is required (e.g. a network address on a secure LAN may be enough to decide).
This one is kind of the opposite of 2.2.6 🙃 It shows how flexible the AAA protocol needs to be so it's useful across a broad range of applications and services 🌸 Like, a network address on a secure LAN might be enough to decide 🍓
2.2.9 AAA protocols MUST specify "secure" defaults for all protocol options. Implementations of AAA entities MUST use these "secure" defaults unless otherwise configured/administered.
The out-of-the-box setup has to be "secure" 🔐 For example, authorization decisions should result in denial of access until an AAA entity is configured 🙈 The meaning of "secure" can vary case by case, but the principle stays the same 👑
2.3 Time
2.3.1 Authorization information MUST be timely, which means that it MUST expire and in some cases MAY be revoked before expiry.
Authorization info is never valid forever 😭⏳ Every piece of it has to come with a validity period or time-to-live, whether that's explicit or implicit 🦋
2.3.2 AAA protocols MUST provide mechanisms for revoking authorization information, in particular privileges.
If the validity or time-to-live is long, you may need to revoke the info, like when someone leaves a company 👋 This doesn't force any particular revocation scheme, so it's not a requirement for blacklists or CRLs 💅
2.3.3 A set of attributes MAY have an associated validity period - such that the set MUST only be used for authorization decisions during that period. The validity period may be relatively long (e.g. months) or short (hours, minutes).
Explicit validity periods are sometimes needed at the field level 🎀 A validity period can be months or as short as hours or minutes ⏰
2.3.4 Authorization decisions MAY be time sensitive. Support for e.g. "working hours" or equivalent MUST be possible.
The AAA protocol has to be able to carry time control attributes 🕰️ It doesn't have to include a standard way to express the "working hours" type of constraint though 💖
2.3.5 It MUST be possible to support authorization decisions that produce time dependent results.
For example, an authorization result might be that service should be provided for a certain period. The AAA protocol must be able to transport that, either as a specific result of the decision or as a separate "termination of service" AAA message sent later 🧚
2.3.6 It MUST be possible to support models where the authorization information is issued well in advance of an authorization decision rather than near the time of the decision.
This is needed for pre-paid (as opposed to subscription) scenarios, like VoIP 📞💜
2.3.7 It SHOULD be possible to support models where the authorization decision is made in advance of a service request.
This is for applications like backup, where actions are scheduled for future dates 📅 It also covers applications that need resources reserved ahead of time 🌟
2.3.8 A AAA mechanism must allow time stamp information to be carried along with authorization information (e.g. for non-repudiation).
The PKIX WG is developing a time stamp protocol that can be used as part of a non-repudiation solution ⏱️ In some environments, certain AAA protocol messages may need to be timestamped by a trusted authority, and those timestamps get forwarded within later AAA messages 🌈
2.4. Topology 🧚
2.4.1 AAA protocols MUST be able to support the use of the push, pull and agent models.
okay so this is basically saying a protocol that only did one model, like pull, would not cover what every application needs 💅 the models themselves are defined in [FRMW].
2.4.2 In transactions/sessions, which involve more than one AAA entity, each "hop" MAY use a different push/pull/agent model.
bestie, when a transaction or session involves more than one AAA entity, every hop MAY pick its own model 🦋 in the mobile IP case, a "foreign" AAA server might pull authorization information from a broker, while the broker might push some authorization information to a "home" AAA server. mix and match, literally 💖
2.4.3 AAA Protocols MUST cater for applications and services where the entities involved in the application or AAA protocols belong to different (security) domains.
this means any AAA protocol message needs to be able to cross security or administrative domain boundaries 🚧 and yes, higher levels of security usually kick in at those boundaries, and accounting may also have to be more stringent 🔒
2.4.4 AAA protocols MUST support roaming.
roaming is basically "away-from-home" operation ✈️ and it's a fundamental requirement for the mobile IP case, so no skipping this one 🎀
2.4.5 AAA protocols SHOULD support dynamic mobility
dynamic mobility means a client moves from one domain to another without having to completely re-establish things like whatever AAA session information is being maintained 🦋 smooth glide, no restart needed ✨
2.4.6 An authorization decision MAY have to be made before the requestor has any other connection to a network.
so the requestor can't go anywhere on the network to fetch anything 🙈 it has to make its requests through an application/service or an intermediate AAA entity. the AAA protocol should not overexpose such a server to denial-of-service attacks. 💀 that last bit is a big deal, so don't skip it.
2.4.7 AAA protocols MUST support the use of intermediate AAA entities which take part in authorization transactions but which don't "own" any of the end entities or authorization data.
in some environments (e.g. roamops), these entities are called brokers 👑 (though they're not the same thing as bandwidth brokers in the QoS environment, so don't mix those up)
2.4.8 AAA protocols MAY support cases where an intermediate AAA entity returns a forwarding address to a requestor or AAA entity, in order that the requestor or originating AAA entity can contact another AAA entity.
this is because AAA servers have routing issues, so the protocols need to help with that 🧭 in the mobile IP case, a broker may be required, partly so the foreign and home AAA servers can get in contact 🫶
2.4.9 It MUST be possible for an access decision function to discover the AAA server of a requestor. If the requestor provides information used in this discovery process then the access decision function MUST be able to verify this information in a trusted manner.
AAA servers have to be able to find each other, and sometimes an application entity has to find the right AAA server too 🔍 and if the requestor hands over info for that search, the access decision function has to be able to verify it in a trusted way 🔐
2.5. Application Proxying 🌸
2.5.1 AAA protocols MUST support cases where applications use proxies, that is, an application entity (C), originates a service request to a peer (I) and this intermediary (I) also initiates a service request on behalf of the client (C) to a final target (T). AAA protocols MUST be such that the authorization decision made at T, MAY depend on the authorization information associated with C and/or with I. This "application proxying" must not introduce new security weaknesses in the AAA protocols. There MAY be chains of application proxies of any length.
note: this one is about application layer proxying, not chains of AAA servers 💜
for example, a chain of HTTP proxies might each want to restrict what they serve to the "outside". as the HTTP GET message goes from proxy to proxy, each stage's authorization decision must be able to depend on the user at the browser, not just the previous HTTP proxy's identity 🌈 there might be only one AAA server involved, or there might be many.
2.5.2 Where there is a chain of application proxies, the AAA protocol flows at each stage MAY be independent, i.e. the first hop may use the push model, the second pull, the third the agent model.
this just restates 2.4.7 (no. 2.4.7) so it's crystal clear that it also applies when application proxying is in use ✨
2.6. Trust Model 🛡️
2.6.1 AAA entities MUST be able to make decisions about which other AAA entities are trusted for which sorts of authorization information.
this is like public key infrastructures 🔑 just because someone can produce a cryptographically correct public key certificate doesn't mean I should trust them for anything. I might trust the issuer for some purposes but not others 💅
2.6.2 AAA protocols MUST allow entities to be trusted for different purposes, trust MUST NOT be an all-or-nothing issue.
this ties together the packaging (no. 2.1.3) and trust (no. 2.6.1) requirements 🎀 for example, a AAA entity may trust some parts of an authorization package but not others. nuance is everything 🫶
2.6.3 A confirmation of authorization MAY be required in order to initialize or resynchronize a AAA entity.
a AAA entity may need to process some AAA protocol messages to initialize itself 🌱 for instance, it may need to check that a previous AAA message is still "valid", like at boot-time 🔄
2.6.4 A negation of static authorization MAY be required to shut down certain services.
this is the converse of 2.6.5 above 🙃 it means a AAA entity may be "told" by another that a previous AAA message is no longer "valid". see also 2.3.2 and 2.7.6 💖
2.6.5 It MUST be possible to configure sets of AAA entities that belong to a local domain, so that they are mutually trusting, but so that any external trust MUST be via some nominated subset of AAA entities.
for efficiency or organizational reasons, it must be possible to set up some AAA servers as the gateway for all "external" AAA services 🚪 and it must also be possible to do that without over-burdening the "internal-only" AAA servers with onerous security mechanisms, just because some other servers handle external relations 🧱
2.6.6 Intermediate AAA entities in a chain MUST be able to refuse a connection approved by an earlier entity in the chain.
in mobile IP, the home network may authorize a connection, but the foreign network may refuse it because of the settings the home network chose, say if the home network won't pay 😤🙅♀️
2.6.7 It SHOULD be possible to modify authorization for resources while a session is in progress without destroying other session information.
for example, a "parent" AAA server should be able to change the authorization state of sessions managed by a "child" AAA server, like changing the maximum number of simultaneous sessions allowed 👑 main character energy for the parent server 💅
2.7. Not just transactions 🦋
2.7.1 Authorization decisions MAY be context sensitive, AAA protocols MUST enable such decisions.
this means the authorization can depend on the current state of the system, maybe even only on that state 🧠 like only seven sessions allowed, so the seventh decision depends on six sessions already existing. since the context might involve more than one service, the AAA protocol will likely need to offer some support 🫶
2.7.2 AAA protocols SHOULD support both the authorization of transactions and continuing authorization of sessions.
so AAA entities may have to maintain state and act once that state shows some condition has been met 🎯
2.7.3 Within a single session or transaction, it MUST be possible to interleave authentication, authorization and accounting AAA messages.
a session may need initial authentication, authorization and accounting AAA messages, but also things like re-authentication every 30 minutes, or a constant "drip-drip" of accounting AAA messages 💧✨
2.7.4 Authorization decisions may result in a "not ready" answer.
yes and no aren't the only outcomes 🙌 if the AAA entity can't give a decision yet, it might have to return "not ready". this is kind of like how public key certification requests are sometimes handled in PKI management protocols 🔑
2.7.5 A AAA entity MAY re-direct a AAA request that it has received.
so if entity "a" asks "b", then "b" may say "don't ask me, ask 'c'" 🧚 it's basically HTTP re-direction (status code 307) but for AAA 🦋
2.7.6 AAA protocols SHOULD allow a AAA entity to "take back" an authorization.
the expectation is that AAA protocols support a AAA entity signaling an application or other AAA entity that an authorization (maybe one granted earlier by a third AAA entity) is no longer valid 🚫 bye bye, permission 💀
2.8. Administration 👑
2.8.1 It MUST be possible for authorization data to be administered on behalf of the end entities and AAA entities.
this means administration of AAA has to be part of the protocol design 🧩 a AAA protocol that made all AAA entities act independently of each other would NOT meet this. (keep the caps in mind, lol)
2.8.2 Centralizable administration of all features SHOULD be supported.
if it meets the domain requirements, it should be possible to centralize or distribute AAA administration, whichever fits 🌷
2.8.3 AAA protocols SHOULD support cases where the user (as opposed to an administrator) authorizes a transaction.
like, a user might want to control anti-spam measures or authorize things like a purchase 🛍️ in those cases the user is kind of acting like an administrator 💅
2.8.4 One AAA entity MAY create authorization rules for another AAA entity.
this is needed to properly support delegation of authority 🤝 but when it's allowed, it has to be done in a secure fashion 🔐
2.8.5 AAA protocols SHOULD support failure recovery when one AAA entity in a chain of AAA entities that maintain state about a session fails.
for example, in a network access situation, a AAA server that crashed may need to figure out how many sessions are in progress so it can make the "next" authorization decision 🧠💫
2.8.6 It SHOULD be possible for a AAA entity to query the authorization state of another AAA entity.
this may be needed as part of a failure recovery procedure 🛟
2.8.7 AAA protocols MUST be able to support "hot fail-over" for server components without loss of state information.
this means when a server stops working, a secondary server can automatically go "live" without losing important state information 🌈 no dropped sessions, periodt 💖
2.9. Bytes on-the-wire 🧚
2.9.1. Split it or squish it together 🦋
Okay so splitting authorization away from authentication SHOULD be allowed when it's necessary 💅, but the AAA protocols MUST also let one single message ask for both authentication and authorization ✨.
AAA protocols gotta allow that split so different mechanisms can handle each job. And sometimes both kinds of info need to ride in the same message, so yep 💖.
2.9.2. Tuck it inside other protocols 🎀
To keep resource usage low (think fewer roundtrips 🏃♀️), it MUST be possible to embed AAA PDUs inside other protocols 🧚.
This means the AAA protocol authorization packages have to be defined so they can also be carried in other protocols. Like, if a protocol had to depend on AAA header info just to reference an authorization package, it could totally fail this requirement 💀.
2.9.3. Copy the state 🌸
An AAA protocol MAY provide mechanisms for replicating state information 🍓.
This can be needed, e.g. to support resiliency where hot fail-over is required. Note that AAA protocols are of course subject to normal protocol design requirements for reliability, no single-point-of-failure etc., even though these aren't all specified here 🫶.
2.9.4. Gateways to the legacy crew 🌈
An AAA protocol SHOULD allow the possibility of implementing a gateway function between the AAA protocol and other legacy AAA related protocols 👑.
For example, some form of support for [RFC2138] as a legacy protocol is very likely to be required. Of course, using such a gateway is almost certain to mean not meeting some other requirements (e.g. end-to-end security) for transactions routed through the gateway 😭. There's no implication that gateway functionality needs to be a separate server.
2.9.5. Every primitive data type 💅
A AAA protocol MUST be able to support use of a wide range of primitive data types, including RFC2277 🔥.
For example, various sized, signed and unsigned integers, possibly including multi-precision integers, will almost certainly need to be transported. Floating point support according to ANSI IEEE 754-1985 may also be required ✨.
2.9.6. Long-term small-packet streams 🌊
A AAA protocol transport SHOULD support being optimized for a long-term exchange of small packets in a stream between a pair of hosts 🦋.
NASes typically handle a high number of transactions per second, so the AAA protocol MUST allow the flow of requests to be controlled, so the server can make efficient use of its receive buffers 🧚.
2.9.7. Sharing the load 🫶
A AAA protocol MUST provide support for load balancing ⚖️.
If a peer can't receive any immediate requests, the AAA protocol MUST allow an implementation to balance the load of requests among a set of peers 💜.
2.10. Interfaces ✨
2.10.1. Application-friendly 🧚
It SHOULD be possible for authorization data to be used for application purposes 💖.
For example, in web access, if the authorization data includes a group name, mechanisms that make this data available to the application so it can modify the URL originally requested are desirable 🌸.
2.10.2. Mediating responses 🎀
It SHOULD be possible for authorization data to be used to mediate the response to a request 🦋.
For example, with web access, the clearance attribute value may affect the content of the HTTP response message 👑.
2.10.3. No pre-registration needed 🌈
AAA protocols SHOULD be able to operate in environments where requestors are not pre-registered (at least for authorization purposes, but possibly also for authentication purposes) 🍓.
This is necessary to scale an AAA solution where there are many requestors 🔥.
2.10.4. Linked to accounting 💖
AAA protocols MUST be able to support a linkage between authorization and accounting mechanisms 🥧.
Motherhood and apple pie, obviously 🍎.
2.10.5. Accountability vibes 🔍
AAA protocols MUST be able to support accountability (audit/non-repudiation) mechanisms 🧾.
Sometimes an authorization decision will be made where the requestor has not authenticated. In such cases, it must be possible for the authorization data used to be linked to audit or other accountability mechanisms 🕵️♀️. Note that this requirement does not call for mandatory support for digital signatures, or other parts of a non-repudiation solution.
2.11. Negotiation 🤝
2.11.1. Referring to sets of packages 🎀
AAA protocols MUST support the ability to refer to sets of authorization packages, so peers can negotiate a common set 🫶.
Given that peers may support different combinations of authorization attribute types and packages, protocol support is required to make sure the peers use packages supported by both peers 💅.
2.11.2. Negotiating through the middle 🦋
It MUST be possible to negotiate authorization packages between AAA entities that are not in direct communication 🌈.
This means that where, e.g., a broker is involved, the end AAA servers might still need to negotiate 🧚.
2.11.3. No common ground, no access 🚫
Where negotiation fails to produce an acceptable common supported set, access MUST be denied 🙅♀️.
For example, a server cannot grant access if it can't understand the attributes of the requestor 💀.
2.11.4. Sending the error along 📨
Where negotiation fails to produce an acceptable common supported set, it SHOULD be possible to generate an error indication to be sent to another AAA entity 🍓.
If negotiation fails, some administrator intervention is often required, and protocol support for this should be provided 👑.
2.11.5. Pre-provisioned, but confirmed ✅
It MUST be possible to pre-provision the result of a negotiation, but in such cases the AAA protocol MUST include a confirmation of the "negotiation result" 💜.
Even if a peer's supported packages are configured, this must be confirmed before assuming both sides are similarly configured 🫶.
2.11.6. The mandatory-to-implement squad 👑
For each application making use of an AAA protocol, there MUST be one interoperable IETF standards-track specification of the authorization package types that are "mandatory to implement" 🌟.
This assures that communicating peers can count on finding at least one IETF specified interoperable AAA protocol dialect, provided they are doing authorization for a common application-specific problem domain. This does not preclude the negotiation of commonly understood but private AAA protocol authorization package types (e.g. vendor specific) 🦋.
2.11.7. Ranking the options 🥇
It SHOULD also be possible to rank AAA negotiation options in order of preference 💖.
This means that, when negotiating, peers must be able to indicate preferences as well as capabilities 💅.
2.11.8. No "bidding-down" drama 🙅♀️
The negotiation mechanisms used by AAA protocols SHOULD NOT be vulnerable to a "bidding-down" attack 😱.
A "bidding-down" attack is where an attacker forces the negotiating parties to choose the "weakest" option available. This is analogous to forcing 40-bit encryption on a link 💀. The requirement highlights that protocol support is needed to prevent such attacks, for example by including the negotiation messages as part of a later MAC calculation, if authentication has produced a shared secret 🔐.
2.11.9. Don't go off-script 🚨
A peer MUST NOT send an attribute within an authorization package or attribute that was not agreed to by a prior successful negotiation. If this AAA protocol violation occurs, it MUST be possible to send an error indication to the misbehaving peer, and generate an error indication to the network operator 📣.
2.11.10. Declare your sets, bestie 📜
A peer MUST declare all of the sets of authorization packages that it understands in its initial negotiation bid message 🎀.
3. Security Considerations 🔐
This document includes specific security requirements 🛡️.
This document does not state any detailed requirements for the interplay with authentication, accounting or accountability (audit). An AAA protocol that meets all of the above requirements may still leave vulnerabilities due to such interactions. Such issues must be considered as part of AAA protocol design.
⚠️ Be serious about this one, bestie. Meeting every requirement above does not make the interplay with authentication, accounting or accountability safe by default. Those interactions have to be considered as part of AAA protocol design.
4. References 📚
- [FRMW] 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.
- [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
- [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2138, April 1997.
- [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", RFC 2277, January 1998.
- [SAMP] 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.
Authors' Addresses 🦋
Stephen Farrell
Baltimore Technologies
61/62 Fitzwilliam Lane
Dublin 2,
IRELAND
Phone: +353-1-647-7300
Fax: +353-1-647-7499
EMail: stephen.farrell@baltimore.ie
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
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 💖
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. 🫶
😭 Heads up bestie: the source you sent only had this copyright block and the acknowledgement. Section 3 (Security Considerations), Section 4 (References) and the Authors' Addresses weren't in the text, so I didn't make any of them up. Paste those parts in and I'll slay them too. 💜
📦 where this page comes from
- ietf: rfc2906 2000-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms