RFC 5176
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
RFC 5176: Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS) ✨
Okay bestie, welcome to RFC 5176! 🎀 It's the Informational doc (not a standards-track one 👀) that describes how RADIUS gets dynamic changes: kicking users off, or changing what a session is allowed to do, while it's already happening. Iconic. 💅
Written by M. Chiba, G. Dommety, and M. Eklund (all from Cisco Systems, Inc.), D. Mitton (RSA, Security Division of EMC), and B. Aboba (Microsoft Corporation). 🧚 It's from the Network Working Group, dated January 2008, and it obsoletes RFC 3576. No updates are listed in its title block. 🌸
Status of This Memo 💌
Okay so this one is just for info, not a rule book. 📖 It's not an Internet standard of any kind, and you're free to share it everywhere because distribution is unlimited. 🦋
Abstract 🌈
This doc is about a currently deployed extension to RADIUS (the Remote Authentication Dial In User Service protocol) that lets you change a user's session on the fly, the way network access server products already do it. 🔥 It covers two big moves: disconnecting users and changing the authorizations that apply to a user's session. Main character energy. 👑
Table of Contents 🗂️
1. Introduction ....................................................2
1.1. Applicability ..............................................3
1.2. Requirements Language ......................................4
1.3. Terminology ................................................4
2. Overview ........................................................4
2.1. Disconnect Messages (DMs) ..................................5
2.2. Change-of-Authorization (CoA) Messages .....................5
2.3. Packet Format ..............................................6
3. Attributes .....................................................10
3.1. Proxy State ...............................................12
3.2. Authorize Only ............................................13
3.3. State .....................................................14
3.4. Message-Authenticator .....................................15
3.5. Error-Cause ...............................................16
3.6. Table of Attributes .......................................20
4. Diameter Considerations ........................................24
5. IANA Considerations ............................................26
6. Security Considerations ........................................26
6.1. Authorization Issues ......................................26
6.2. IPsec Usage Guidelines ....................................27
6.3. Replay Protection .........................................28
7. Example Traces .................................................28
8. References .....................................................29
8.1. Normative References ......................................29
8.2. Informative References ....................................30
9. Acknowledgments ................................................30
Appendix A ........................................................311. Introduction 🎀
So, RADIUS (defined in [RFC2865]) has a big limitation: the RADIUS server can't just send a message to the Network Access Server (NAS) out of nowhere. 🙈 It can only talk when it's spoken to first.
But honestly, there are tons of times you'd want to change a session without the NAS starting the conversation. 🫶 For example, an admin might need to end user sessions that are in progress. Or, if a user's authorization level changes, you may need to add or remove authorization attributes from their sessions. Real-life problems, bestie. 😭
So a bunch of vendors built their own extra RADIUS commands to let the server send unsolicited messages to the NAS. ✨ These commands are Disconnect and Change-of-Authorization (CoA) packets. Disconnect packets kill user sessions immediately, while CoA packets modify session authorization attributes, like data filters. 💅
1.1. Applicability 🦋
This protocol is being recommended for publication as an Informational RFC rather than as a standards-track RFC. Why? Because some problems can't be fixed without breaking the implementations people already use. 💀 That includes security vulnerabilities, plus semantic ambiguities that come from how the Change-of-Authorization (CoA) commands were designed. Fixes are recommended, but they can't be made mandatory, since that would be incompatible with existing implementations. 🙃
Existing implementations don't do authorization checks. So an ISP sharing a NAS with another ISP could disconnect or change authorizations for the other ISP's users. 😱 Not it. To fix this, a "Reverse Path Forwarding" check is described. See Section 6.1 for the details. 🔐
Existing implementations also use per-packet authentication and integrity protection algorithms that have known weaknesses [MD5Attack]. For stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 6.2 for details. 🛡️
Existing implementations also lack replay protection. To support replay detection, it is recommended that an Event-Timestamp Attribute be added to all packets in situations where IPsec replay protection is not employed. See Section 6.3 for details. ⏰
The CoA commands in existing implementations create a semantic ambiguity, and this is the tea. ☕ Existing implementations of the CoA-Request identify the affected session and supply the authorization changes. Since RADIUS Attributes in the CoA-Request can be used for session identification or for authorization change, it may not be clear what job a given attribute is doing. Confusing, bestie. 🌀
The Diameter protocol [RFC3588] doesn't have this problem. 👑 There, a server-initiated authorization change uses a Re-Auth-Request (RAR) command. The RAR identifies the session via User-Name and Session-Id Attribute Value Pairs (AVPs) and contains a Re-Auth-Request-Type AVP with the value AUTHORIZE_ONLY. This starts a standard Request/Response sequence where the authorization changes are supplied. So in Diameter, no command has AVPs with multiple potential meanings. Clean. ✨
1.2. Requirements Language 🌸
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📚
1.3. Terminology 🧚
This document uses the following terms a lot, so let's get them down:
- Dynamic Authorization Client (DAC): The entity that sends Change of Authorization (CoA) Requests or Disconnect-Requests. The DAC can live on the same box as a RADIUS authentication or accounting server, but it doesn't have to. 🍓
- Dynamic Authorization Server (DAS): The entity that receives CoA-Request or Disconnect-Request packets. The DAS can be a NAS or a RADIUS proxy. 🦋
- Network Access Server (NAS): The device that provides access to the network. 🌐
- service: The NAS provides a service to the user, such as IEEE 802 or Point-to-Point Protocol (PPP). 💜
- session: Each service the NAS provides to a user is a session. A session starts at the point where service is first provided and ends at the point where service is ended. A user can have multiple sessions in parallel or in series, if the NAS supports that. 🎀
- silently discard: The implementation throws the packet away without any further processing. 🙈 It SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter. Logging and counting, not dramatic at all. 📊
2. Overview 🌈
This section covers the most commonly implemented features of Disconnect and Change-of-Authorization (CoA) packets. ✨
2.1. Disconnect Messages (DMs) 💖
A Disconnect-Request packet is sent by the Dynamic Authorization Client to terminate user session(s) on a NAS and discard all associated session context. The packet goes to UDP port 3799, and it identifies both the NAS and the user session(s) to be terminated by including the identification attributes described in Section 3. 🔥
+----------+ +----------+
| | Disconnect-Request | |
| | <-------------------- | |
| NAS | | DAC |
| | Disconnect-ACK/NAK | |
| | ---------------------> | |
+----------+ +----------+The NAS responds to a Disconnect-Request from a Dynamic Authorization Client with a Disconnect-ACK if all associated session context is discarded and the user session(s) are no longer connected. If the NAS couldn't disconnect one or more sessions and discard all their context, it sends a Disconnect-NAK instead. 🙅♀️ A Disconnect-ACK MAY contain the Acct-Terminate-Cause (49) Attribute [RFC2866] with the value set to 6 for Admin-Reset. Optional flex, bestie. 💅
2.2. Change-of-Authorization (CoA) Messages 🦋
CoA-Request packets carry information for dynamically changing session authorizations. Usually this is used to change data filters. The data filters can be either ingress or egress, and they're sent alongside the identification attributes described in Section 3. The port and packet format (described in Section 2.3) are the same as for Disconnect-Request packets. 🧚
The following attributes MAY be sent in a CoA-Request: 🎀
Filter-ID (11): Names a data filter list to be applied for the session(s) that the identification attributes map to. 🍓NAS-Filter-Rule (92): Provides a filter list to be applied for the session(s) that the identification attributes map to [RFC4849]. 💜
+----------+ +----------+
| | CoA-Request | |
| | <-------------------- | |
| NAS | | DAC |
| | CoA-ACK/NAK | |
| | ---------------------> | |
+----------+ +----------+The NAS responds to a CoA-Request from a Dynamic Authorization Client with a CoA-ACK if it successfully changes the authorizations for the user session(s). If the CoA-Request fails, the NAS sends a CoA-NAK instead. 😤 A NAS MUST respond to a CoA-Request that includes a Service-Type Attribute with an unsupported value by sending a CoA-NAK. An Error-Cause Attribute with the value "Unsupported Service" SHOULD be included too. 🙌
Okay, that's the first chunk! 🌸 More parts are coming, so stay tuned. 🫶
2.3. Packet Format ✨
okay bestie, let's talk packets 📦. For both Disconnect-Request and CoA-Request, the destination port is UDP port 3799 🎀. For responses, the source and destination ports swap. Exactly one RADIUS packet lives inside the UDP Data field, no sharing 💅.
Here's the data format at a glance. The fields go left to right 👀.
The packet is made of Code, Identifier, Length, Authenticator, and Attributes in Type-Length-Value (TLV) format 🧚. Every field means the same thing it does in RADIUS [RFC2865], so nothing new to learn there 🫶. The Authenticator MUST be calculated the same way as for an Accounting-Request in [RFC2866] 🔐.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-Code
The Code field is one octet and tells you what kind of RADIUS packet you're holding 🦋. Packets with an invalid Code field MUST be silently discarded, so no drama, just gone 👋. Here are the decimal codes for this extension:
40 - Disconnect-Request [RFC3575]
41 - Disconnect-ACK [RFC3575]
42 - Disconnect-NAK [RFC3575]
43 - CoA-Request [RFC3575]
44 - CoA-ACK [RFC3575]
45 - CoA-NAK [RFC3575]Identifier
The Identifier field is one octet and helps match requests with replies 🌸. A Dynamic Authorization Server implementing this specification MUST be capable of detecting a duplicate request if it has the same source IP address, source UDP port, and Identifier within a short span of time 👑.
Retransmitting Disconnect-Request and CoA-Request packets is the Dynamic Authorization Client's job 🫡. If it sends one of these and gets no response, it will retransmit 🔁.
The Identifier field MUST be changed whenever the content of the Attributes field changes, or whenever a valid reply has been received for a previous request 💜. For retransmissions where the contents are identical, the Identifier MUST remain unchanged ✨.
If the Dynamic Authorization Client is retransmitting a Disconnect-Request or CoA-Request to the same Dynamic Authorization Server as before, and the attributes haven't changed, the same Request Authenticator, Identifier, and source port MUST be used 🎀. If any attributes have changed, a new Authenticator and Identifier MUST be used 🌈.
If the Request to a primary Dynamic Authorization Server fails, a secondary Dynamic Authorization Server must be queried, if available. Failover algorithm issues are covered in [RFC3539] 🧠. Since this counts as a new request, a new Request Authenticator and Identifier MUST be used 💅.
Heads up: when the Dynamic Authorization Client is sending directly to the NAS, failover typically doesn't make sense 🙈. CoA-Request or Disconnect-Request packets need to reach the NAS where the session lives, so backup servers aren't the move there.
Length
The Length field is two octets 📏. It shows the length of the whole packet, including the Code, Identifier, Length, Authenticator, and Attributes fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception 🫧. If the packet is shorter than the Length field says, it MUST be silently discarded 🗑️. The minimum length is 20 and the maximum length is 4096 🍓.
Authenticator
The Authenticator field is sixteen (16) octets long 🔒. The most significant octet is transmitted first. This value authenticates packets between the Dynamic Authorization Client and the Dynamic Authorization Server 🫶.
Request Authenticator
In Request packets, the Authenticator value is a 16-octet MD5 [RFC1321] checksum, called the Request Authenticator 🧁. It's calculated the same way as for an Accounting-Request, specified in [RFC2866] 📝.
Note that the Request Authenticator of a CoA-Request or Disconnect-Request cannot be computed the same way as the Request Authenticator of a RADIUS Access-Request 🙅♀️. The reason is that there is no User-Password Attribute in a CoA-Request or Disconnect-Request 💀.
Response Authenticator
The Authenticator field in a Response packet (for example, Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response Authenticator 🌟. It holds a one-way MD5 hash, calculated over a stream of octets made of the Code, Identifier, Length, the Request Authenticator field from the packet being replied to, and the response attributes if any, followed by the shared secret 🔑. The resulting 16-octet MD5 hash goes into the Authenticator field of the Response packet 🎉.
Administrative note: As noted in [RFC2865], Section 3, the secret (the password shared between the Dynamic Authorization Client and the Dynamic Authorization Server) SHOULD be at least as large and unguessable as a well-chosen password 🔐. The Dynamic Authorization Server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied 🛰️.
Attributes
In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory 📋. If one or more authorization changes specified in a CoA-Request cannot be carried out, the NAS MUST send a CoA-NAK 🚫.
A NAS MUST respond to a CoA-Request containing one or more unsupported attributes or Attribute values with a CoA-NAK. An Error-Cause Attribute with value 401 (Unsupported Attribute) or 407 (Invalid Attribute Value) MAY be included 🧩. A NAS MUST respond to a Disconnect-Request containing one or more unsupported attributes or Attribute values with a Disconnect-NAK. An Error-Cause Attribute with value 401 (Unsupported Attribute) or 407 (Invalid Attribute Value) MAY be included 💅.
State changes from a CoA-Request MUST be atomic 💖. If the CoA-Request succeeds for all matching sessions, the NAS MUST send a CoA-ACK in reply, and all requested authorization changes MUST be made 🎀. If the CoA-Request fails for any matching sessions, the NAS MUST send a CoA-NAK in reply, and the requested authorization changes MUST NOT be made for any of the matching sessions 😭.
Same energy for Disconnect-Request: a state change MUST NOT occur as a result of a Disconnect-Request that is unsuccessful with respect to any of the matching sessions. A NAS MUST send a Disconnect-NAK in reply if any of the matching sessions cannot be successfully terminated 🙅♀️.
A NAS that does not support dynamic authorization changes applying to multiple sessions MUST send a CoA-NAK or Disconnect-NAK in reply. An Error-Cause Attribute with value 508 (Multiple Session Selection Unsupported) SHOULD be included 🌈.
Within this specification, attributes can be used for identification, authorization, or other purposes ✨. RADIUS Attribute specifications created after publication of this document SHOULD state whether an attribute can be included in CoA or Disconnect messages. If it can, they SHOULD also say which messages it can be included in, and whether it serves as an identification or authorization attribute 📚.
Even if a NAS implements an attribute for use with RADIUS authentication and accounting, it's possible it won't support including that attribute in CoA-Request and Disconnect-Request packets, because the attribute semantics are different 🦋. This is true even for attributes allowed within Access-Accept packets, such as those defined within [RFC2865], [RFC2868], [RFC2869], [RFC3162], [RFC3579], [RFC4372], [RFC4675], [RFC4818], and [RFC4849] 🫶.
3. Attributes ✨
okay so this part is all about the attributes 🎀 Disconnect-Request and CoA-Request packets need to name the NAS and the session(s) on it, so the NAS can tell which session to hit. The NAS and session identification attributes you include have to match at least one session for the Request to work, or you get a Disconnect-NAK or CoA-NAK back. If all the NAS identification attributes match and more than one session fits all the session identification attributes, the CoA-Request or Disconnect-Request MUST apply to every matching session. bestie that's a big deal 💀
Here are the identification attributes, grouped by NAS and session, exactly as the spec lists them:
NAS identification attributes
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Session identification attributes
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with one or
more sessions.
NAS-Port 5 [RFC2865] The port on which a
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with a session.
Vendor-Specific 26 [RFC2865] One or more vendor-specific
identification attributes.
Called-Station-Id 30 [RFC2865] The link address to which
a session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
one or more sessions are
connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying a session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Id 87 [RFC2869] String identifying the port
where a session is.
Chargeable-User- 89 [RFC4372] The CUI associated with one
Identity or more sessions. Needed
where a privacy Network
Access Identifier (NAI) is
used, since in this case the
User-Name (e.g., "anonymous")
may not identify sessions
belonging to a given user.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with a session,
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with a session, always sent
with Framed-Interface-Id.Security-wise, the spec says either the User-Name or Chargeable-User-Identity SHOULD be present in Disconnect-Request and CoA-Request packets, to deal with the concerns in Section 6.1 🔒 ngl that's the kind of detail you do NOT skip.
If a Diameter client uses the same Session-Id for both authorization and accounting, putting an Acct-Session-Id in a Disconnect-Request or CoA-Request can help with Diameter/RADIUS translation, since Diameter RAR and ASR commands carry a Session-Id AVP. An Acct-Session-Id SHOULD be included in Disconnect-Request and CoA-Request packets 🦋
A NAS implementing this spec SHOULD send an Acct-Session-Id or Acct-Multi-Session-Id within an Access-Request. If it doesn't, the Dynamic Authorization Client won't know the Acct-Session-Id or Acct-Multi-Session-Id of the session it's trying to target, unless it also has access to that session's accounting data 🙈
And if neither Acct-Session-Id nor Acct-Multi-Session-Id is in the CoA-Request or Disconnect-Request, User-Name or Chargeable-User-Identity might not be enough to pin down one session. Like, if the same user has several sessions on the NAS, or the privacy NAI is in use, it's giving confusion 😭 In that case, if you want to identify one specific session, you MAY use one or more of Framed-IP-Address, Framed-IPv6-Prefix/Framed-Interface-Id, Called-Station-Id, Calling-Station-Id, NAS-Port, and NAS-Port-Id.
To help RADIUS proxies route Request packets to the right destination, one or more of NAS-IP-Address or NAS-IPv6-Address SHOULD be present in CoA-Request and Disconnect-Request packets. NAS-Identifier MAY be present too. Impersonation issues with the NAS Identification attributes are covered in [RFC3579], Section 4.3.7 🧚
A Disconnect-Request MUST contain only NAS and session identification attributes. If anything else shows up in a Disconnect-Request, implementations MUST send a Disconnect-NAK, and an Error-Cause Attribute with the value "Unsupported Attribute" MAY be included. no extra stuff allowed, periodt 💅
The DAC may need data from RADIUS authentication or accounting packets, and it uses that data to build compliant CoA-Request or Disconnect-Request packets. For example, as Section 3.3 describes, a CoA-Request with a Service-Type Attribute set to "Authorize Only" is required to contain a State Attribute. The NAS will then send that attribute to the RADIUS server in an Access-Request. So for the DAC to include a State Attribute the RADIUS server will actually accept, the two parties may need to coordinate 🤝
There are a few ways to make that coordination happen. The DAC can be co-located with a RADIUS server, in which case it's presumed to have the data it needs. The RADIUS server can also keep that info in a common database. The DAC can then live separately from the RADIUS server, as long as it can reach that common database 🌸
If the DAC isn't co-located with a RADIUS server and doesn't have access to a common database, the DAC SHOULD send CoA-Request or Disconnect-Request packets to a RADIUS server acting as a proxy, instead of sending them straight to the NAS.
A RADIUS server that gets a CoA-Request or Disconnect-Request from the DAC MAY add or update attributes before forwarding it. Examples are adding NAS or session identification attributes, or appending a State Attribute. Having a RADIUS server forward CoA/Disconnect-Requests can also let upstream RADIUS proxies do a Reverse Path Forwarding (RPF) check (see Section 6.1) 👑
3.1. Proxy State 🍓
If the Disconnect-Request or CoA-Request from the Dynamic Authorization Client has any Proxy-State attributes, the Dynamic Authorization Server MUST include those Proxy-State attributes in its response to the Dynamic Authorization Client.
A forwarding proxy or NAS MUST NOT modify existing Proxy-State, State, or Class attributes in the packet. It MUST treat any Proxy-State attributes already there as opaque data, and its operation MUST NOT depend on the content of Proxy-State attributes added by previous proxies. A forwarding proxy MUST NOT modify any other Proxy-State attributes in the packet. It can choose not to forward them, but it MUST NOT change their contents. If the forwarding proxy leaves out the Proxy-State attributes in the request, it MUST attach them to the response before sending it back 🫶
When a proxy forwards a Disconnect-Request or CoA-Request, it MAY add a Proxy-State Attribute, but it MUST NOT add more than one. If it does add one, that Proxy-State Attribute MUST be added after any existing Proxy-State attributes. The forwarding proxy MUST NOT change the order of any attributes of the same type, Proxy-State included. Other attributes can go before, after, or even between the Proxy-State attributes ✨
When a proxy gets a response to a CoA-Request or Disconnect-Request, it MUST remove its own Proxy-State Attribute (the last Proxy-State in the packet) before forwarding the response. Disconnect and CoA responses are authenticated over the entire packet contents, so stripping the Proxy-State Attribute breaks the integrity check, and the proxy MUST recompute it. it's like, a whole chain reaction 💥
3.2. Authorize Only 🌈
To make translation between RADIUS and Diameter simpler, Dynamic Authorization Clients can include a Service-Type Attribute with the value "Authorize Only" in a CoA-Request. Section 4 has the details on Diameter considerations. Support for a CoA-Request with a Service-Type Attribute of "Authorize Only" is OPTIONAL on both the NAS and the Dynamic Authorization Client. A Service-Type Attribute MUST NOT be included in a Disconnect-Request 🦋
A NAS MUST respond to a CoA-Request with a Service-Type Attribute of "Authorize Only" with a CoA-NAK, and a CoA-ACK MUST NOT be sent. If the NAS doesn't support the Service-Type value "Authorize Only", it MUST respond with a CoA-NAK, and an Error-Cause Attribute with the value 405 (Unsupported Service) SHOULD be included 🙃
A CoA-Request with a Service-Type Attribute of "Authorize Only" MUST, in addition, contain only NAS or session identification attributes, as well as a State Attribute. If any other attributes are in that CoA-Request, a CoA-NAK MUST be sent, and an Error-Cause Attribute with the value 401 (Unsupported Attribute) SHOULD be included 💀
If a CoA-Request with the Service-Type value "Authorize Only" is processed successfully, the NAS MUST respond with a CoA-NAK that contains a Service-Type Attribute with the value "Authorize Only" and an Error-Cause Attribute with the value 507 (Request Initiated). Then the NAS MUST send an Access-Request to the RADIUS server, including a Service-Type Attribute with the value "Authorize Only" along with a State Attribute. That Access-Request SHOULD contain the NAS identification attributes from the CoA-Request, plus the session identification attributes from the CoA-Request that are allowed in an Access-Request. It MAY also contain other attributes that are allowed in an Access-Request 🧚♀️
As [RFC2869], Section 5.19 notes, a Message-Authenticator attribute SHOULD be included in an Access-Request that doesn't contain a User-Password, CHAP-Password, ARAP-Password, or EAP-Message Attribute. The RADIUS server will then answer that Access-Request with an Access-Accept to (re-)authorize the session, or an Access-Reject to refuse to (re-)authorize it 🎀
3.3. State
okay so the State Attribute is the one that's basically a sticky note 🧚 The Dynamic Authorization Client can send it to the NAS in a CoA-Request packet, and the NAS MUST send it back unmodified to the Dynamic Authorization Client in a subsequent ACK or NAK packet 💌
[RFC2865], Section 5.44 is the bit that makes this matter. Here's what it says:
An Access-Request MUST contain either a User-Password or a CHAP-Password or State. An Access-Request MUST NOT contain both a User-Password and a CHAP-Password. If future extensions allow other kinds of authentication information to be conveyed, the attribute for that can be used in an Access-Request instead of User-Password or CHAP-Password.
So to keep [RFC2865], Section 5.44 happy, an Access-Request with a Service-Type Attribute set to "Authorize Only" MUST contain a State Attribute 🫶
Now for the Authorize Only flow ✨ A Dynamic Authorization Client that sends a CoA-Request with a Service-Type Attribute set to "Authorize Only" MUST include a State Attribute, and the NAS MUST send that State Attribute unmodified to the RADIUS server in the resulting Access-Request, if there is one. If a NAS gets a CoA-Request with "Authorize Only" but no State Attribute, it MUST send a CoA-NAK, and it SHOULD include an Error-Cause Attribute with a value of 402 (Missing Attribute) 💀
State also shows up with a Termination-Action Attribute set to RADIUS-Request 🌸 If the NAS does the Termination-Action by sending a new Access-Request when the current session ends, it MUST include the State Attribute unchanged in that Access-Request. Either way, the Dynamic Authorization Server MUST NOT interpret the Attribute locally 🙈 A CoA-Request packet MUST have only zero or one State Attribute. How State gets used is implementation dependent 🔥
3.4. Message-Authenticator
The Message-Authenticator Attribute MAY be used to authenticate and integrity-protect CoA-Request, CoA-ACK, CoA-NAK, Disconnect-Request, Disconnect-ACK, and Disconnect-NAK packets, which is how you stop spoofing 🦋
A Dynamic Authorization Server that receives a CoA-Request or Disconnect-Request with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it doesn't match the value sent. A Dynamic Authorization Client that receives a CoA/Disconnect-ACK or CoA/Disconnect-NAK with a Message-Authenticator Attribute present MUST do the same check: calculate the correct value and silently discard the packet if it doesn't match the value sent 💅
When a Message-Authenticator Attribute is included within a CoA-Request or Disconnect-Request, it's calculated like this:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)When the HMAC-MD5 message integrity check is calculated, the Request Authenticator field and Message-Authenticator Attribute MUST each be considered to be sixteen octets of zero. The Message-Authenticator Attribute is calculated and inserted in the packet before the Request Authenticator is calculated 🎀
When a Message-Authenticator Attribute is included within a CoA-ACK, CoA-NAK, Disconnect-ACK, or Disconnect-NAK, it's calculated like this:
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)When the HMAC-MD5 message integrity check is calculated, the Message-Authenticator Attribute MUST be considered to be sixteen octets of zero. The Request Authenticator is taken from the corresponding CoA/Disconnect-Request. The Message-Authenticator is calculated and inserted in the packet before the Response Authenticator is calculated 🧚
3.5. Error-Cause
Description
Okay, this one is the drama queen of the attributes 😭 It's possible that a Dynamic Authorization Server can't honor a Disconnect-Request or CoA-Request packet for some reason. That's where Error-Cause comes in, giving more detail on what went wrong. It MAY be included within CoA-NAK and Disconnect-NAK packets 💜
Here's the format, read left to right:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Type
101 for Error-Cause 🍓
Length
6 🌈
Value
The Value field is four octets and holds an integer that specifies the cause of the error. Values 0-199 and 300-399 are reserved 🫠 Values 200-299 are successful completions, so they can only be sent within CoA-ACK or Disconnect-ACK packets, and they MUST NOT be sent within a CoA-NAK or Disconnect-NAK packet. Values 400-499 are fatal errors committed by the Dynamic Authorization Client, so they MAY be sent within CoA-NAK or Disconnect-NAK packets, and they MUST NOT be sent within CoA-ACK or Disconnect-ACK packets. Values 500-599 are fatal errors occurring on a Dynamic Authorization Server, so they MAY be sent within CoA-NAK and Disconnect-NAK packets, and they MUST NOT be sent within CoA-ACK or Disconnect-ACK packets. Error-Cause values SHOULD be logged by the Dynamic Authorization Client 📝 Error-Code values (in decimal) look like this:
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
407 Invalid Attribute Value
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
508 Multiple Session Selection UnsupportedNow let's go through what each one means 👑
"Residual Session Context Removed" gets sent in response to a Disconnect-Request when one or more user sessions are no longer active, but leftover session context was found and successfully removed. This value is only sent within a Disconnect-ACK, and it MUST NOT be sent within a CoA-ACK, Disconnect-NAK, or CoA-NAK ✨
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification 🙈
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (like a Vendor-Specific or EAP-Message Attribute) that isn't supported 💅
"Missing Attribute" is a fatal error sent if critical attributes (like NAS or session identification attributes) are missing from a Request 😭
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3) don't match the identity of the NAS receiving the Request 🫶
"Invalid Request" is a fatal error sent if some other part of the Request is invalid, like if one or more attributes (such as EAP-Message Attribute(s)) aren't formatted properly 💀
"Unsupported Service" is a fatal error sent if a Service-Type Attribute in the Request has an invalid or unsupported value. This error cannot be sent in response to a Disconnect-Request 🌸
"Unsupported Extension" is a fatal error sent because the extension isn't supported, such as Disconnect and/or CoA packets. This will typically be sent by a proxy that gets an ICMP port unreachable message after trying to forward a CoA-Request or Disconnect-Request to the NAS 🦋
"Invalid Attribute Value" is a fatal error sent if a CoA-Request or Disconnect-Request contains an attribute with an unsupported value 🎀
"Administratively Prohibited" is a fatal error sent if the NAS is configured to refuse honoring CoA-Request or Disconnect-Request packets for the specified session 🔥
"Request Not Routable" is a fatal error that MAY be sent by a proxy and MUST NOT be sent by a NAS. It means the proxy couldn't figure out how to route a CoA-Request or Disconnect-Request to the NAS. For example, this can happen if the required entries aren't in the proxy's realm routing table 🗺️
"Session Context Not Found" is a fatal error sent if the session context identified in the CoA-Request or Disconnect-Request doesn't exist on the NAS 🧚
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request when the NAS found the session context but couldn't remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK, or Disconnect-ACK, only within a Disconnect-NAK 💜
"Other Proxy Processing Error" is a fatal error sent in response to a CoA or Disconnect-Request that a proxy couldn't process, for reasons other than routing 🌈
"Resources Unavailable" is a fatal error sent when a CoA or Disconnect-Request can't be honored because the NAS is out of resources (memory, non-volatile storage, etc.) 🍓
"Request Initiated" is a fatal error sent by a NAS in response to a CoA-Request that includes a Service-Type Attribute set to "Authorize Only". It means the CoA-Request hasn't been honored, but the NAS is sending one or more RADIUS Access-Requests with a Service-Type Attribute set to "Authorize Only" to the RADIUS server 🌸
"Multiple Session Selection Unsupported" is a fatal error sent by a NAS in response to a CoA-Request or Disconnect-Request whose session identification attributes match multiple sessions, when the NAS doesn't support Requests that apply to multiple sessions 🫶
3.6. Table of Attributes ✨
okay so this is the cheat sheet bestie 📋 it tells you which attributes can show up in which packets, and how many of each you're allowed to have 💅 the columns are Request, ACK, and NAK, plus the attribute number and name. the tables are split up by message type, so read the right one 🫶
Change-of-Authorization Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name (Note 1)
0-1 0 0 4 NAS-IP-Address (Note 1)
0-1 0 0 5 NAS-Port (Note 1)
0-1 0 0-1 6 Service-Type
0-1 0 0 7 Framed-Protocol (Note 3)
0-1 0 0 8 Framed-IP-Address (Notes 1, 6)
0-1 0 0 9 Framed-IP-Netmask (Note 3)
0-1 0 0 10 Framed-Routing (Note 3)
0+ 0 0 11 Filter-ID (Note 3)
0-1 0 0 12 Framed-MTU (Note 3)
0+ 0 0 13 Framed-Compression (Note 3)
0+ 0 0 14 Login-IP-Host (Note 3)
0-1 0 0 15 Login-Service (Note 3)
0-1 0 0 16 Login-TCP-Port (Note 3)
0+ 0 0 18 Reply-Message (Note 2)
0-1 0 0 19 Callback-Number (Note 3)
0-1 0 0 20 Callback-Id (Note 3)
0+ 0 0 22 Framed-Route (Note 3)
0-1 0 0 23 Framed-IPX-Network (Note 3)
0-1 0-1 0-1 24 State
0+ 0 0 25 Class (Note 3)
0+ 0 0 26 Vendor-Specific (Note 7)
0-1 0 0 27 Session-Timeout (Note 3)
0-1 0 0 28 Idle-Timeout (Note 3)
0-1 0 0 29 Termination-Action (Note 3)
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 30 Called-Station-Id (Note 1)
0-1 0 0 31 Calling-Station-Id (Note 1)
0-1 0 0 32 NAS-Identifier (Note 1)
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 34 Login-LAT-Service (Note 3)
0-1 0 0 35 Login-LAT-Node (Note 3)
0-1 0 0 36 Login-LAT-Group (Note 3)
0-1 0 0 37 Framed-AppleTalk-Link (Note 3)
0+ 0 0 38 Framed-AppleTalk-Network (Note 3)
0-1 0 0 39 Framed-AppleTalk-Zone (Note 3)
0-1 0 0 44 Acct-Session-Id (Note 1)
0-1 0 0 50 Acct-Multi-Session-Id (Note 1)
0-1 0-1 0-1 55 Event-Timestamp
0+ 0 0 56 Egress-VLANID (Note 3)
0-1 0 0 57 Ingress-Filters (Note 3)
0+ 0 0 58 Egress-VLAN-Name (Note 3)
0-1 0 0 59 User-Priority-Table (Note 3)
0-1 0 0 61 NAS-Port-Type (Note 3)
0-1 0 0 62 Port-Limit (Note 3)
0-1 0 0 63 Login-LAT-Port (Note 3)
0+ 0 0 64 Tunnel-Type (Note 5)
0+ 0 0 65 Tunnel-Medium-Type (Note 5)
0+ 0 0 66 Tunnel-Client-Endpoint (Note 5)
0+ 0 0 67 Tunnel-Server-Endpoint (Note 5)
0+ 0 0 69 Tunnel-Password (Note 5)
0-1 0 0 71 ARAP-Features (Note 3)
0-1 0 0 72 ARAP-Zone-Access (Note 3)
0+ 0 0 78 Configuration-Token (Note 3)
0+ 0-1 0 79 EAP-Message (Note 2)
0-1 0-1 0-1 80 Message-Authenticator
0+ 0 0 81 Tunnel-Private-Group-ID (Note 5)
0+ 0 0 82 Tunnel-Assignment-ID (Note 5)
0+ 0 0 83 Tunnel-Preference (Note 5)
0-1 0 0 85 Acct-Interim-Interval (Note 3)
0-1 0 0 87 NAS-Port-Id (Note 1)
0-1 0 0 88 Framed-Pool (Note 3)
0-1 0 0 89 Chargeable-User-Identity (Note 1)
0+ 0 0 90 Tunnel-Client-Auth-ID (Note 5)
0+ 0 0 91 Tunnel-Server-Auth-ID (Note 5)
0-1 0 0 92 NAS-Filter-Rule (Note 3)
0 0 0 94 Originating-Line-Info
0-1 0 0 95 NAS-IPv6-Address (Note 1)
0-1 0 0 96 Framed-Interface-Id (Notes 1, 6)
0+ 0 0 97 Framed-IPv6-Prefix (Notes 1, 6)
0+ 0 0 98 Login-IPv6-Host (Note 3)
0+ 0 0 99 Framed-IPv6-Route (Note 3)
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 100 Framed-IPv6-Pool (Note 3)
0 0 0+ 101 Error-Cause
0+ 0 0 123 Delegated-IPv6-Prefix (Note 3)
Request ACK NAK # AttributeDisconnect Messages
Request ACK NAK # Attribute
0-1 0 0 1 User-Name (Note 1)
0-1 0 0 4 NAS-IP-Address (Note 1)
0-1 0 0 5 NAS-Port (Note 1)
0 0 0 6 Service-Type
0 0 0 8 Framed-IP-Address (Note 1)
0+ 0 0 18 Reply-Message (Note 2)
0 0 0 24 State
0+ 0 0 25 Class (Note 4)
0+ 0 0 26 Vendor-Specific (Note 7)
0-1 0 0 30 Called-Station-Id (Note 1)
0-1 0 0 31 Calling-Station-Id (Note 1)
0-1 0 0 32 NAS-Identifier (Note 1)
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 44 Acct-Session-Id (Note 1)
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id (Note 1)
0-1 0-1 0-1 55 Event-Timestamp
0 0 0 61 NAS-Port-Type
0+ 0-1 0 79 EAP-Message (Note 2)
0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 87 NAS-Port-Id (Note 1)
0-1 0 0 89 Chargeable-User-Identity (Note 1)
0-1 0 0 95 NAS-IPv6-Address (Note 1)
0 0 0 96 Framed-Interface-Id (Note 1)
0 0 0 97 Framed-IPv6-Prefix (Note 1)
0 0 0+ 101 Error-Cause
Request ACK NAK # Attributeso how do you read those little symbols? 🤔 here's the decoder ring 💖
0means this attribute MUST NOT be present in the packet 🚫0+means zero or more instances of this attribute MAY be present in the packet 🌈0-1means zero or one instance of this attribute MAY be present in the packet 🦋1means exactly one instance of this attribute MUST be present in the packet 👑
now the notes, which are where the juicy stuff is 🫶
(Note 1) when NAS or session identification attributes show up in Disconnect-Request or CoA-Request packets, they're only there for identification 🔍 these attributes MUST NOT be used for anything else, like sneaking in an authorization change inside a CoA-Request 🙅♀️
(Note 2) the Reply-Message Attribute is how you show the user a message they can actually read 💌 it only gets displayed if the Disconnect-Request or CoA-Request was a success and a Disconnect-ACK or CoA-ACK goes back out after it 🎀 when Extension Authentication Protocol (EAP) is doing the authentication, you send an EAP-Message/Notification-Request Attribute instead, and the Disconnect-ACK or CoA-ACK packets carry an EAP-Message/Notification-Response Attribute back 🔁
(Note 3) when these attributes are in a CoA-Request, they're asking for an authorization change 🔥 if one gets left out of the CoA-Request, the NAS assumes its value stays exactly the same 🧚 and any attributes that DO show up in a CoA-Request replace every existing value of that same attribute 💅
(Note 4) when the Class Attribute is inside a successful Disconnect-Request (the kind that gets a Disconnect-ACK after), it SHOULD be passed along untouched by the NAS to the RADIUS accounting server in the Accounting Stop packet 🍓 if the Disconnect-Request fails, the Class Attribute is not processed at all 🙈
(Note 5) when these tunnel attributes are in a CoA-Request, they're an authorization change request too 🌸 if they show up in a successful CoA-Request, every existing tunnel attribute gets wiped out and replaced by the new ones 🧹
(Note 6) okay this one's a plot twist 😭 you can't renumber a session by putting Framed-IP-Address, Framed-IPv6-Prefix, or Framed-Interface-Id values in a CoA-Request, because those are the attributes used to identify the session in the first place 🪪 instead you send a CoA-Request with a Service-Type Attribute set to "Authorize Only", and the new values come back in an Access-Accept sent in response to the Access-Request that follows 🦋 also, renumbering won't always work 🥲 changing an IP address might need IPCP or IPv6CP re-negotiation, and not every PPP implementation supports that 🌈
(Note 7) this one is about Vendor-Specific Attributes (VSAs) 💜 in Disconnect-Request packets, VSAs MAY be used for session identification ✨ in CoA-Request packets, VSAs MAY be used for either session identification or an authorization change 💫 but the same Attribute MUST NOT be used for both purposes at the same time 🚨
4. Diameter Considerations ✨
okay so translating change-of-authorization stuff between RADIUS and Diameter is NOT always a vibe, bestie 😭. They handle these requests differently, so it can be hard or even impossible for a Diameter/RADIUS gateway to turn a Diameter Re-Auth-Request (RAR) into a CoA-Request, or the other way around. For example, a CoA-Request only starts an authorization change and does not start re-authentication, so a RAR with a Re-Auth-Request-Type AVP set to "AUTHORIZE_AUTHENTICATE" can't be directly translated into a CoA-Request 💀. When a gateway gets a CoA-Request with authorization changes, it has to turn that into two Diameter exchanges 🎀. First, it sends a RAR with a Session-Id AVP and a Re-Auth-Request-Type AVP set to "AUTHORIZE ONLY". Then it answers the access request that follows with a response carrying the authorization attributes it pulled from the CoA-Request ✨. To make translation possible, the CoA-Request SHOULD include an Acct-Session-Id Attribute 🫶. If the Diameter client uses the same Session-Id for both authorization and accounting, the gateway can copy the Acct-Session-Id Attribute's contents into the Session-Id AVP. Otherwise, it has to map the Acct-Session-Id value to an equivalent Session-Id for use in a RAR command 🧚.
If a CoA-Request or Disconnect-Request doesn't have an Acct-Session-Id Attribute, the gateway has two options. It can figure out the right Acct-Session-Id itself, or, if it can't, it can reply with a CoA-NAK or Disconnect-NAK. That reply might also include an Error-Cause Attribute with value 508 (Multiple Session Selection Unsupported) 🙈.
To make RADIUS and Diameter translation easier, Dynamic Authorization Clients can include a Service-Type Attribute with the value "Authorize Only" inside a CoA-Request, as described in Section 3.2 💅. When a gateway gets a CoA-Request with a Service-Type Attribute set to "Authorize Only", it translates that into a RAR with a Re-Auth-Request-Type AVP set to "AUTHORIZE ONLY". The RAA it gets back is then translated into a CoA-NAK with a Service-Type Attribute set to "Authorize Only". If the Result-Code AVP in the RAA has a value in the success category, the CoA-NAK includes an Error-Cause Attribute with the value "Request Initiated" 🌸. If the Result-Code AVP has a value that means a Protocol Error or a Transient or Permanent Failure, an alternate Error-Cause Attribute is returned, as suggested below 👑.
Inside Diameter, a server can ask for a session to be aborted by sending an Abort-Session-Request (ASR). That ASR identifies the session to end using the Session-ID and User-Name AVPs 🦋. The ASR gets translated into a Disconnect-Request that contains the Acct-Session-Id and User-Name attributes. If the Diameter client uses the same Session-Id for authorization and accounting, the value of the Session-ID AVP can go into the Acct-Session-Id Attribute. Otherwise, the Session-ID AVP value has to be mapped to a proper Acct-Session-Id Attribute 🍓. To make it possible to translate a Disconnect-Request back into an ASR, an Acct-Session-Id Attribute SHOULD be present 🔥.
If the Diameter client uses the same Session-Id for authorization and accounting, the value of the Acct-Session-Id Attribute may go into the Session-ID AVP within the ASR. Otherwise, the Acct-Session-Id Attribute value has to be mapped to an appropriate Session-ID AVP 💖.
An Abort-Session-Answer (ASA) is sent in response to an ASR to show what happened to the request 💅. When a Diameter/RADIUS gateway gets a Disconnect-ACK, it translates that into an ASA with a Result-Code AVP of "DIAMETER_SUCCESS". A Disconnect-NAK from the NAS gets translated into an ASA whose Result-Code AVP depends on the value of the Error-Cause Attribute. The suggested mappings between Error-Cause Attribute values and Result-Code AVP values are below 🌈:
# Error-Cause Attribute Value Result-Code AVP
--- --------------------------- ------------------------
201 Residual Session Context DIAMETER_SUCCESS
Removed
202 Invalid EAP Packet DIAMETER_LIMITED_SUCCESS
(Ignored)
401 Unsupported Attribute DIAMETER_AVP_UNSUPPORTED
402 Missing Attribute DIAMETER_MISSING_AVP
403 NAS Identification DIAMETER_REALM_NOT_SERVED
Mismatch
404 Invalid Request DIAMETER_UNABLE_TO_COMPLY
405 Unsupported Service DIAMETER_COMMAND_UNSUPPORTED
406 Unsupported Extension DIAMETER_APPLICATION_UNSUPPORTED
407 Invalid Attribute Value DIAMETER_INVALID_AVP_VALUE
501 Administratively DIAMETER_AUTHORIZATION_REJECTED
Prohibited
502 Request Not Routable (Proxy) DIAMETER_UNABLE_TO_DELIVER
503 Session Context Not Found DIAMETER_UNKNOWN_SESSION_ID
504 Session Context Not DIAMETER_AUTHORIZATION_REJECTED
Removable
505 Other Proxy Processing DIAMETER_UNABLE_TO_COMPLY
Error
506 Resources Unavailable DIAMETER_RESOURCES_EXCEEDED
507 Request Initiated DIAMETER_SUCCESSSince both the ASR/ASA exchange and the Disconnect-Request/Disconnect-NAK/Disconnect-ACK exchange are just a request and a response, putting an "Authorize Only" Service-Type inside a Disconnect-Request isn't needed for RADIUS/Diameter translation. It can actually make translation harder 🙈. So, as noted in Section 3.2, the Service-Type Attribute MUST NOT be used within a Disconnect-Request. That's a hard no, babe 🚫.
5. IANA Considerations 🎀
This document uses the RADIUS [RFC2865] namespace. You can find it at <http://www.iana.org/assignments/radius-types>. On top of the allocations already made in [RFC3575] and [RFC3576], this specification allocates new values of the Error-Cause Attribute (101) 🧚:
# Value
--- -----
407 Invalid Attribute Value
508 Multiple Session Selection Unsupported6. Security Considerations 🔥
This section is serious business, so pay attention, bestie 😤.
6.1. Authorization Issues
When a NAS is shared by several providers, it's not okay for one provider to be able to send Disconnect-Requests or CoA-Requests that affect another provider's sessions 🙅♀️.
A Dynamic Authorization Server MUST silently discard Disconnect-Request or CoA-Request packets from untrusted sources. When the Dynamic Authorization Client lives on the same machine as a RADIUS authentication or accounting server, a proxy MAY do a "reverse path forwarding" (RPF) check to confirm that a Disconnect-Request or CoA-Request comes from an authorized Dynamic Authorization Client 🔍. It also SHOULD be possible to explicitly authorize extra sources of Disconnect-Request or CoA-Request packets for certain classes of sessions 🦋. For example, one particular source can be explicitly authorized to send CoA-Request packets for users in a set of realms 🌸.
To do the RPF check, the Dynamic Authorization Server uses the session identification attributes in the Disconnect-Request or CoA-Request packets. That tells it which RADIUS server(s) an equivalent Access-Request could be routed to. If the source address of the Disconnect-Request or CoA-Request is in that set, the CoA-Request or Disconnect-Request is forwarded. Otherwise, it MUST be silently discarded 💀.
Usually, the Dynamic Authorization Server pulls the realm out of the Network Access Identifier [RFC4282] inside the User-Name or Chargeable-User-Identity Attribute, then figures out the matching RADIUS servers from the realm routing tables ✨. If the Dynamic Authorization Server keeps long-term session state, it MAY do the authorization check using the session identification attributes in the CoA-Request. Those attributes can tie a session to a particular proxy or set of proxies, the same way the NAI realm does 🫶.
When there's no proxy, the NAS is the only one who can do the RPF check, and only if it keeps its own realm routing table. If the NAS doesn't keep a realm routing table (for example, it picks forwarding proxies based on primary/secondary configuration and/or liveness checks), then an RPF check can't be done at all 😭.
Since whether you're allowed to send a Disconnect-Request or CoA-Request is decided by the source address and the matching shared secret, the Dynamic Authorization Server SHOULD configure a different shared secret for each Dynamic Authorization Client 🔐.
6.2. IPsec Usage Guidelines
Besides the security problems unique to Disconnect or CoA packets, the protocol exchanges in this document are open to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be used for better security, following the profile described in [RFC3579], Section 4.2 🛡️.
For Dynamic Authorization Servers that implement this specification, the IPsec policy would be "Require IPsec, from any to me, destination port UDP 3799". That makes the Dynamic Authorization Server require IPsec. If some Dynamic Authorization Clients don't support IPsec, you'll need a more granular policy: "Require IPsec, from IPsec-Capable-DAC to me" 💜.
For Dynamic Authorization Clients that implement this specification, the IPsec policy would be "Initiate IPsec, from me to any, destination port UDP 3799". That makes the Dynamic Authorization Client start IPsec whenever it sends Dynamic Authorization traffic to any Dynamic Authorization Server 🚀. If some Dynamic Authorization Servers the client contacts don't support IPsec, you'll need a more granular policy, such as "Initiate IPsec, from me to IPsec-Capable-DAS, destination port UDP 3799" 🌈.
6.3. Replay Protection 🦋
Okay so, if IPsec replay protection isn't being used, an Event-Timestamp (55) [RFC2869] Attribute SHOULD be included within CoA-Request and Disconnect-Request packets, and MAY be included within CoA-ACK, CoA-NAK, Disconnect-ACK, and Disconnect-NAK packets. 🎀
When the Event-Timestamp Attribute is present, both the Dynamic Authorization Server and the Dynamic Authorization Client MUST check that it's current within an acceptable time window. ⏰ If it isn't current, the packet MUST be silently discarded. 🙈 This means the network needs loose time synchronization, which you can get in a bunch of ways, including Simple Network Time Protocol (SNTP), as described in [RFC4330]. Implementations SHOULD be configurable to discard CoA-Request or Disconnect-Request packets that don't contain an Event-Timestamp Attribute. 💅
If the Event-Timestamp Attribute is included, it shows the time the original packet was sent, so it SHOULD NOT be updated when the packet is retransmitted. ✨ If it isn't updated, the Identifier also isn't changed in retransmitted packets. So being able to detect a replay within the time window depends on duplicate detection working inside that same window. As noted in Section 2.3, duplicate detection is REQUIRED for Dynamic Authorization Servers implementing this specification. 👑
The time window used for duplicate detection MUST be the same as the window used to detect a stale Event-Timestamp Attribute. 🧚 Since the RADIUS Identifier can't be repeated within the selected time window, no more than 256 Requests can be accepted within that window. So the chosen window depends on the expected maximum volume of CoA/Disconnect-Requests, which helps you avoid unnecessary discards. 🌸 A default time window of 300 seconds should be adequate in many circumstances. 💖
7. Example Traces 🍓
Here's a Disconnect Request with User-Name: 🧾
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261Next up, a Disconnect Request with Acct-Session-ID: 🦋
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567And last, a Disconnect Request with Framed-IP-Address: 🌈
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 02038. References 📚
8.1. Normative References
- [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
- [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
- [RFC2865] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
- [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
- [RFC2869] Rigney, C., Willats W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
- [RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
- [RFC3575] Aboba, B., "IANA Considerations for RADIUS", RFC 3575, July 2003.
- [RFC3579] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
- [RFC4282] Aboba, B., Beadles, M., Arkko, J. and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
8.2. Informative References
- [MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
- [RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting Transport Profile", RFC 3539, June 2003.
- [RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
- [RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
- [RFC4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI", RFC 4330, January 2006.
- [RFC4372] Adrangi, F., Lior, A., Korhonen, J. and J. Loughney, "Chargeable User Identity", RFC 4372, January 2006.
- [RFC4675] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Attributes for Virtual LAN and Priority Support", RFC 4675, September 2006.
- [RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.
- [RFC4849] Congdon, P., Sanchez, M. and B. Aboba, "RADIUS Filter Rule Attribute", RFC 4849, April 2007.
9. Acknowledgments 🫶
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit. ✨
The authors would like to thank everyone who gave valuable suggestions and feedback: Avi Lior, Randy Bush, Steve Bellovin, Glen Zorn, Mark Jones, Claudio Lapidus, Anurag Batta, Kuntal Chowdhury, Tim Moore, Russ Housley, Joe Salowey, Alan DeKok, and David Nelson. 💜
Appendix A. Changes from RFC 3576 📝
This Appendix lists the major changes between [RFC3576] and this document. Minor changes, including style, grammar, spelling, and editorial changes, aren't mentioned here.
- The term "Dynamic Authorization Client" is used instead of RADIUS server where it applies to the originator of CoA-Request and Disconnect-Request packets. The term "Dynamic Authorization Server" is used instead of NAS where it applies to the receiver of CoA-Request and Disconnect-Request packets. Definitions of these terms have been added (Section 1.3).
- Added requirement for duplicate detection on the Dynamic Authorization Server (Section 2.3).
- Clarified expected behavior when session identification attributes match more than one session (Sections 2.3, 3, 3.5, 4).
- Added Chargeable-User-Identity as a session identification attribute. Removed NAS-Port-Type as a session identification attribute (Section 3).
- Added recommendation that an Acct-Session-Id or Acct-Multi-Session-Id Attribute be included in an Access-Request (Section 3).
- Added discussion of scenarios in which the "Dynamic Authorization Client" and RADIUS server are not co-located (Section 3).
- Added details relating to handling of the Proxy-State Attribute (Section 3.1).
- Added clarification that support for a Service-Type Attribute with value "Authorize Only" is optional on both the NAS and Dynamic Authorization Client (Section 3.2). Use of the Service-Type Attribute within a Disconnect-Request is prohibited (Sections 3.2, 3.6).
- Added requirement for inclusion of the State Attribute in CoA-Request packets including a Service-Type Attribute with a value of "Authorize Only" (Section 3.3).
- Added clarification on the calculation of the Message-Authenticator Attribute (Section 3.4).
- Additional Error-Cause Attribute values are allocated for Invalid Attribute Value (407) and Multiple Session Selection Identification (508) (Sections 3.5, 4).
- Updated the CoA-Request Attribute Table to include Filter-Rule, Delegated-IPv6-Prefix, Egress-VLANID, Ingress-Filters, Egress-VLAN-Name, and User-Priority attributes (Section 3.6).
- Added the Chargeable-User-Identity Attribute to both the CoA-Request and Disconnect-Request Attribute table (Section 3.6).
- Use of Vendor-Specific Attributes (VSAs) for session identification and authorization change has been clarified (Section 3.6).
- Added Note 6 on the use of the CoA-Request for renumbering, and Note 7 on the use of Vendor-Specific attributes (Section 3.6).
- Added Diameter Considerations (Section 4).
- Event-Timestamp Attribute should not be recalculated on retransmission. The implications for replay and duplicate detection are discussed (Section 6.3).
- Operation of the Reverse Path Forwarding (RPF) check has been clarified. Use of the RPF check is optional rather than recommended by default (Section 6.1).
- Text on impersonation (included in [RFC3579], Section 4.3.7) and IPsec operation (included in [RFC3579], Section 4.2) has been removed, and is now referenced.
Authors' Addresses 🌷
Murtaza Chiba
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose CA, 95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton
RSA, Security Division of EMC
174 Middlesex Turnpike
Bedford, MA 01730
EMail: david@mitton.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329Full Copyright Statement ⚖️
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property 🔥
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5176 2008-01
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms