RFC 5997
Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
RFC 5997: Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol 🎀
Okay bestie, let's start with the title block tea ☕ This RFC was written by A. DeKok from FreeRADIUS and published in August 2010 🌸. It's an Informational RFC, not a Standards Track one, and its ISSN is 2070-1721. It updates RFC 2866 💅. The title block doesn't list anything it obsoletes.
Abstract 🌟
okay so this doc describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol that lets clients check the status of a RADIUS server 👀 It uses the Status-Server (12) Code, which RFC 2865 had reserved for experimental use. literally the perfect little glow-up for an old code 💖
Status of This Memo 📜
this one's not an Internet Standards Track spec, it's just published for info 🦋
it's an Internet Engineering Task Force (IETF) product and it represents the consensus of the IETF community ✨ it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 🧚
for the latest status, errata, and how to send feedback, head to http://www.rfc-editor.org/info/rfc5997 💜
Copyright Notice ©️
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date. read them carefully, bestie, because they spell out your rights and restrictions for this doc 📖 any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 🔥
some material in this doc might come from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process 🙈 so unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. the only exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌸
Table of Contents 📚
1. Introduction ....................................................3
1.1. Applicability ..............................................3
1.2. Terminology ................................................4
1.3. Requirements Language ......................................4
2. Overview ........................................................4
2.1. Why Access-Request is Inappropriate ........................6
2.1.1. Recommendation against Access-Request ...............7
2.2. Why Accounting-Request is Inappropriate ....................7
2.2.1. Recommendation against Accounting-Request ...........7
3. Packet Format ...................................................8
3.1. Single Definition for Status-Server .......................10
4. Implementation Notes ...........................................10
4.1. Client Requirements .......................................11
4.2. Server Requirements .......................................12
4.3. Failover with Status-Server ...............................14
4.4. Proxy Server Handling of Status-Server ....................14
4.5. Limitations of Status-Server ..............................15
4.6. Management Information Base (MIB) Considerations ..........17
4.6.1. Interaction with RADIUS Server MIB Modules .........17
4.6.2. Interaction with RADIUS Client MIB Modules .........17
5. Table of Attributes ............................................18
6. Examples .......................................................19
6.1. Minimal Query to Authentication Port ......................19
6.2. Minimal Query to Accounting Port ..........................20
6.3. Verbose Query and Response ................................21
7. Security Considerations ........................................21
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................23
Acknowledgments ...................................................241. Introduction ✨
this doc specifies that same deployed RADIUS extension: it lets clients query the status of a RADIUS server 🫶 RFC 2865 defined the Status-Server (12) Code as experimental in [RFC2865], Section 3, but it didn't explain how the Code works or what it could be used for, so that's the gap this doc fills 💅
like the core RADIUS protocol, the Status-Server extension is stateless. queries don't otherwise affect how a server normally operates and don't cause any side effects, except maybe bumping an internal packet counter 🦋 most implementations of this extension run alongside RADIUS implementations as defined in [RFC2865], so this document focuses only on using the extension over UDP transport 🌈
quick roadmap, bestie 🗺️ Section 2 has the problem statement and explains why some possible solutions can cause unwanted side effects. Section 3 defines the Status-Server packet format. Section 4 covers client and server requirements plus some implementation notes. Section 5 has a RADIUS table of attributes. the rest of the text covers security considerations that aren't handled elsewhere in the document 🔥
1.1. Applicability 🎀
okay this protocol is being recommended for publication as an Informational RFC instead of a Standards-Track RFC, and the reason is problems with deployed implementations 😭 that includes security vulnerabilities 💀 the fixes recommended here work with existing servers that receive Status-Server packets, but they add new security requirements for clients that send them 🔐
some existing implementations don't support the Message-Authenticator attribute ([RFC3579]). that lets an unauthorized client spoof Status-Server packets, which could lead to incorrect Access-Accepts 🙃 to fix this, this specification requires the use of the Message-Authenticator attribute, which gives per-packet authentication and integrity protection 💖
another thing: with existing implementations, a Status-Server request could clash with an Access-Request or Accounting-Request packet that uses the same Identifier 😵💫 this specification recommends techniques to avoid that problem 🌸
we'll dig into these limitations in more detail below 🫶
1.2. Terminology 📖
this doc uses the following terms:
"Network Access Server (NAS)"
the device that provides access to the network. also known as the Authenticator (in IEEE 802.1X terminology) or the RADIUS client 🧚
"RADIUS Proxy"
to route RADIUS authentication and accounting requests, you can use a RADIUS proxy. to the NAS, the RADIUS proxy looks like a RADIUS server, and to the RADIUS server, the proxy looks like a RADIUS client 🦋
"silently discard"
this means the implementation throws the packet away without any further processing 🗑️ the implementation MAY offer the option of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter 📊
1.3. Requirements Language 💜
in this document, a few words signal the specification's requirements, and the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119] 🔥✨
that's the end of part 1! Part 2 picks up with Section 2, bestie, so stay tuned 🧚💅
2. Overview ✨
Okay so, Status-Server packets are how a RADIUS client checks whether a RADIUS server is alive 💖. The destination is set to the IP address and port of the server being tested. A single Status-Server packet MUST be included within a UDP datagram. A Message-Authenticator attribute MUST be included too, so every packet gets per-packet authentication and integrity protection 🔐.
RADIUS proxies or servers MUST NOT forward Status-Server packets 🚫. A RADIUS server or proxy implementing this specification SHOULD respond to a Status-Server packet with an Access-Accept (authentication port) or Accounting-Response (accounting port) 🎀. An Access-Challenge response is NOT RECOMMENDED, and an Access-Reject response MAY be used. The attributes that are allowed in Status-Server packets, and in Access-Accept or Accounting-Response packets replying to them, are listed in Section 5. Section 6 has a bunch of examples 🧚.
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the client only learns the status of that one server. No RADIUS proxies sit on the path between the client and server, so there's nothing else in the middle to blame 😌. Servers answer a Status-Server packet without looking at the User-Name attribute, which means the reply can't tell you anything about whether specific realms are reachable 🙅♀️.
The "hop-by-hop" thing is the main point here. Status-Server packets are super useful for a client trying to figure out the status of the very first element on the path between itself and a server 🦋. Because the packet can't be forwarded, a missing reply can only be caused by packet loss or by the server at the destination IP address being down. It can't be a problem with downstream links, proxies, or servers further along. That makes it an unambiguous signal of server status, which is so clean 👑.
This info is handy when the RADIUS client isn't getting any response to an Access-Request 🥺. A client might have multiple proxies configured, with one marked as primary and another marked as secondary. If the client doesn't hear back from a request sent to the primary proxy, it can "failover" and send its requests to the secondary proxy instead.
BUT, and this is a big but 💀, the silence from the primary might not be the primary's fault at all. It could be a failed link on the way to the destination server, or the destination server itself might be the problem.
So it's really helpful for the client to be able to tell the causes apart, so it doesn't trigger failover when it shouldn't 🙈. For example, if the primary proxy is actually down, a quick failover to the secondary is the smart move 🏃♀️. But if the problem is somewhere downstream, failing over only helps if the secondary's packets take independent links, intermediaries, or destination servers. Otherwise it's not really a fix.
A Status-Server packet is NOT a "Keep-Alive" as described in [RFC2865], Section 2.6 🙅♀️. "Keep-Alives" are Access-Request packets that get sent to figure out whether a downstream server is responsive. They're usually only sent when a server is suspected to be down, and they stop as soon as the server is back up.
2.1. Why Access-Request is Inappropriate
One possible way to check server status is for a NAS to send specially made Access-Request packets to a RADIUS server's authentication port 🤔. The NAS can then watch for a response and use it to decide whether the server is active or unresponsive.
Here's the catch though: the server might treat the request like a normal login for a real user and conclude that a real person just logged onto that NAS 😬. It could then take actions that are really not wanted for a simple status check. It might also reply with an Access-Challenge, which means it thinks an extended authentication conversation is needed.
Another option is that the server replies with an Access-Reject, meaning the user isn't authorized to get onto the network. Just like before, the server might do local-site stuff too, like warning an admin about failed login attempts 📣. It could also delay the Access-Reject as a way of rate-limiting failed auth attempts, the old-school way. That delay means the admin asking the question can't tell if the server is down, slow, or just deliberately stalling 😵💫.
Using Access-Request queries can also mean the server has local users whose only reason to exist is to make these query requests work 🫠. Unless the server policy is designed really carefully, an attacker might be able to use those credentials to get unauthorized network access 🚨.
Also, some NAS implementations already send Access-Request packets like this, using a fixed (and non-configurable) user name and password 🤦♀️. Because of implementation problems in that gear, if a RADIUS server doesn't answer those queries, the NAS might mark it as unresponsive. That can happen even when the server is happily answering other Access-Request packets from the same NAS. Admins then get super confused trying to figure out why an active server got labeled "unresponsive" 💀.
2.1.1. Recommendation against Access-Request
For all the reasons above, NAS implementors SHOULD NOT generate Access-Request packets just to see if a server is alive 🙅♀️. In the same way, site administrators SHOULD NOT configure test users whose only reason to exist is to enable those Access-Request queries.
Quick note though: test users can still be really useful for end-to-end or in-depth testing of a server policy 🧪. This is super common, but I'm asking admins to be careful with it, okay? 🫶
2.2. Why Accounting-Request is Inappropriate
A similar idea for checking server status is for a NAS to send specially made Accounting-Request packets to a RADIUS server's accounting port 📦. The NAS can watch for a response and use that to figure out whether the server is active or unresponsive.
Same drama as before: the server might conclude that a real user has logged onto a NAS and do local-site actions that are undesirable for a simple status query 😤.
Another problem is that some attributes are mandatory in an Accounting-Request. That forces the admin to query an accounting server with fake values for those attributes in a test packet 🙃. Those fake values make a simple query way more work, and they can pollute the server's accounting database with incorrect data 🗑️.
2.2.1. Recommendation against Accounting-Request
For all the reasons above, NAS implementors SHOULD NOT generate Accounting-Request packets just to see if a server is alive 🙅♀️. In the same way, site administrators SHOULD NOT configure accounting policies whose only reason to exist is to enable those Accounting-Request queries.
Again, test users can still be useful for performing end-to-end or in-depth testing of a server's policy 🧪. It's widespread, but admins should use it with care, bestie 💅✨
3. Packet Format ✨
okay so Status-Server packets are literally just RADIUS packets 💅 they reuse the packet format and the fields and values from [RFC2865], Section 3. I'm not copying over all the text and diagrams from that section, bestie. Instead I'm going to walk you through what's different so you can actually implement Status-Server 🦋
The Authenticator field of Status-Server packets MUST be generated the same way as the Request Authenticator field of Access-Request packets (more on that below) 🔥
The Identifier field works the same for Status-Server as it does for every other packet. BUT here's the tea: Status-Server is basically doing the job of an Access-Request or Accounting-Request, so there's a real chance a Status-Server request could clash with an Access-Request or Accounting-Request that has the same Identifier. 😭 In Section 4.2 below, we describe a method for avoiding these problems. That method MUST be used to avoid conflicts between Status-Server and other packet types. no exceptions, periodt 💜
Request Authenticator
In Status-Server packets, the Authenticator value is a 16-octet random number called the Request Authenticator 🎀 It SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server). Why? Because if a request value gets repeated with the same secret, an attacker could reply with a response they intercepted earlier. 💀 Since the same secret MAY be used to authenticate with servers in totally different geographic regions, the Request Authenticator field SHOULD be globally and temporally unique too. If you want ideas on generating random numbers, check out [RFC4086] 🌈
The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable 🙈 The reason is that if an attacker could trick a server into responding to a predicted future request, they could grab that response and pretend to be that server when a client sends a future Status-Server request. Not it!
Now, the response side. The Response Authenticator field of an Access-Accept packet that's sent back for a Status-Server query MUST be generated the same way it would be for an Access-Request. The only swap is that the Status-Server Request Authenticator takes the place of the Access-Request Request Authenticator ✨
Same energy for Accounting-Response: the Response Authenticator of an Accounting-Response packet sent back for a Status-Server query MUST be generated the way it would be for an Accounting-Request, with the Status-Server Request Authenticator stepping in for the Accounting-Request Request Authenticator 👑
Also, when a server responds to a Status-Server request, it MUST NOT send more than one Response packet. one reply only, bestie 🙅♀️
Response Authenticator
The value of the Authenticator field in Access-Accept or Accounting-Response packets is called the Response Authenticator, and it's a one-way MD5 hash 🔮 It gets calculated over a stream of octets made up of: the RADIUS packet starting from the Code field (including the Identifier, the Length, and the Request Authenticator field from the Status-Server packet), plus the response Attributes (if there are any), followed by the shared secret. Here's the formula:
ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)where + just means concatenation 🧚
Okay, now the extra rules that apply on top of everything above. All Status-Server packets MUST include a Message-Authenticator attribute 🛡️ If you skip it, the packets could be trivially spoofed, so it's not optional, it's a must.
Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-Address or NAS-IPv6-Address. These attributes aren't needed for Status-Server to work at all 🍓 but they might be useful info for a server that gets those packets.
Any other attributes SHOULD NOT be included in a Status-Server packet, and if they do show up, they MUST be ignored. ✨ Then there's the stuff that is just a hard no: user authentication credentials like User-Name, User-Password, CHAP-Password, and EAP-Message MUST NOT appear in a Status-Server packet sent to a RADIUS authentication port 🙅♀️ And user or NAS accounting attributes like Acct-Session-Id, Acct-Status-Type, and Acct-Input-Octets MUST NOT appear in a Status-Server packet sent to a RADIUS accounting port. Absolutely not 💀
The Access-Accept MAY contain a Reply-Message or Message-Authenticator attribute. It SHOULD NOT contain other attributes 🌸 And the Accounting-Response packets that go back for a Status-Server query SHOULD NOT contain any attributes at all. Why? Because the whole point is a simple query, not user authentication or accounting, so there's basically zero reason to pile extra attributes into either the query or the reply 💅
Examples of Status-Server packet flows are coming up in Section 6 🎀
3.1. Single Definition for Status-Server
When Status-Server packets get sent to a RADIUS accounting port, their contents are still calculated exactly the way we described above 🦋 Even though they're going to an accounting port, they are NOT created the same way Accounting-Requests are. Yes, that's a plot twist, and it actually has some perks. ✨
Having one single definition for Status-Server packets is way simpler than having different definitions for different destination ports 🧠 Also, if we had defined Status-Server to look like an Accounting-Request but with no attributes, those packets could be trivially forged. Not cute 😭
So we define Status-Server consistently, and only the response packet changes depending on which port the request was sent to. If the request goes to an authentication port, the response is an Access-Accept packet. If it goes to an accounting port, the response is an Accounting-Response packet 👑
4. Implementation Notes 🌈
There are a bunch of things to think about when you implement Status-Server support, so this section covers the implementation details and requirements for RADIUS clients and servers that support Status-Server 🫶
The following text applies to both the authentication and accounting ports. To keep things simple, we use these generic terms:
- Request packet: An Access-Request packet sent to an authentication port, or an Accounting-Request packet sent to an accounting port.
- Response packet: An Access-Accept, Access-Challenge, or Access-Reject packet sent from an authentication port, or an Accounting-Response packet sent from an accounting port.
We also call the originator of the Status-Server packet the "client," and the receiver of that packet (which is also the originator of the Response packet) the "server." 💖
Using these generic terms is way easier than duplicating the same text for authentication and accounting packets. Efficiency is everything, bestie ✨
4.1. Client Requirements
Clients SHOULD let administrators globally enable or disable the generation of Status-Server packets 🎀 The default SHOULD be that it's disabled. Also, since it's not great to send queries to servers that don't support Status-Server, clients SHOULD have a per-server configuration that says whether or not to enable Status-Server for a particular destination. The default SHOULD be disabled here too 🙈
The client SHOULD use a watchdog timer, like the one defined in Section 2.2.1 of [RFC5080], to figure out when to send Status-Server packets ⏰
Now, the retransmission rule is kind of a big deal. When Status-Server packets are sent from a client, they MUST NOT be retransmitted 🚫 Instead, the Identity field MUST be changed every single time a packet is transmitted. The old packet should be discarded, and a brand new Status-Server packet gets generated and sent, with a new Identity and new Authenticator fields. Fresh start, every time 🦋
Clients MUST include the Message-Authenticator attribute in all Status-Server packets 🛡️ Skip it, and the packets could be trivially spoofed, which could lead to potential denial-of-service (DoS) attacks. Yikes 😭 Other attributes SHOULD NOT appear in a Status-Server packet, except as outlined below in Section 5. The whole point is a simple status query, so there's little reason for any extra attributes to show up 💅
The client MAY increment packet counters because it sent a Status-Server request or because it received a Response packet 📈 But the client MUST NOT do any other action that would normally happen when it receives a Response packet, like letting a user have login access to a port. Stay in your lane, client 🙅♀️
Clients MAY send Status-Server requests to the RADIUS destination ports from the same source port they use for normal Request packets. Other clients MAY choose to send Status-Server requests from a unique source port that isn't used for Request packets 🌸
Okay, so why suggest a unique source port? It helps match responses to requests 🧚 Since the response to a Status-Server packet is an Access-Accept or Accounting-Response packet, those responses look exactly the same as other packets sent back in response to a Request packet. So the best way to tell them apart from everything else is to give them their own port 🎀
A client MAY send a Status-Server packet from a source port that's also used for Request packets. In that case, the Identifier field MUST be unique across all outstanding Request packets for that source port, no matter what the RADIUS Code field is for those outstanding requests. 🔐 Once the client has either gotten a response to the Status-Server packet or decided that it timed out, it may reuse that Identifier in another packet ✨
Robust implementations SHOULD accept any Response packet as a valid response to a Status-Server packet, as long as it passes the validation requirements we defined above for the Response Authenticator 🛡️ The Code field matters less than the fact that a valid, signed response showed up. Vibes over labels 💜
Here's the process, step by step. Before the client accepts a response as valid, it should check that the Response packet Code field is either Access-Accept (2) or Accounting-Response (5). If the Code doesn't match either of those values, the packet MUST be silently discarded 🙈 Then the client MUST validate the Response Authenticator using the algorithm given above in Section 3. If the Response Authenticator isn't valid, the packet MUST be silently discarded. And if the Response Authenticator IS valid, then the packet MUST be deemed a valid response from the server ✅
Why does this matter so much? If the client threw out a response just because the packet Code wasn't what it expected, it could accidentally discard valid responses from a server and mark that server as unresponsive 😭 That would mess with the stability of a RADIUS network, because perfectly responsive servers would get wrongly marked as unresponsive. So we recommend that clients should be liberal in what they accept as responses to Status-Server queries 🫶💖
4.2. Server Requirements 🎀
Okay bestie, servers SHOULD let admins flip Status-Server acceptance on or off globally 🔥. The default SHOULD be that acceptance is enabled ✨. Servers SHOULD also let admins turn acceptance on or off per client 💅. The default SHOULD be that acceptance is enabled 🫶.
Status-Server packets from clients that aren't allowed to send the server Request packets MUST be silently discarded 🙈. If a server doesn't support Status-Server packets, or is set up not to respond to them, then it MUST silently discard the packet 💀.
We note that [RFC2865], Section 3, defines a bunch of RADIUS Codes but doesn't say which Codes are valid for port 1812 🧚. In contrast, [RFC2866], Section 3, says only RADIUS Accounting packets are to be sent to port 1813 📚. This specification is compatible with [RFC2865], since it uses a known Code for packets to port 1812 🌈. It is not compatible with [RFC2866], though, because it adds a new Code (Status-Server) that's valid for port 1812 😭. However, since the category of [RFC2866] is Informational, this conflict is acceptable 🦋.
Servers SHOULD silently discard Status-Server packets if they determine that a client is sending too many Status-Server requests in a particular time period 🍓. How a server makes that call is implementation specific and out of scope for this specification 🌸.
If a server supports Status-Server packets, is configured to respond to them, and receives a packet from a known client, it MUST validate the Message-Authenticator attribute as defined in [RFC3579], Section 3.2 🔐. Packets that fail that validation MUST be silently discarded 🗑️.
Servers SHOULD NOT otherwise discard Status-Server packets if they have recently sent the client a Response packet 👑. The query may have come from an admin who doesn't have access to the Response packet stream, or from one who wants more info about the server 🧚♀️.
The server MAY prioritize the handling of Status-Server packets over the handling of other requests, subject to the rate limiting described above 🔥.
The server MAY decide not to respond to a Status-Server, depending on local-site policy 💅. For example, a server that is running but can't do its normal activities MAY silently discard Status-Server packets 💀. That can happen when a server needs a database for normal operation but the connection to that database is down 🙈. Or it may happen when the accepted load on the server is lower than the offered load 📉.
Some server implementations require that Access-Request packets be accepted only on "authentication" ports (e.g., 1812/udp), and that Accounting-Request packets be accepted only on "accounting" ports (e.g., 1813/udp) 🎀. Those implementations SHOULD reply to Status-Server packets sent to an "authentication" port with an Access-Accept packet, and SHOULD reply to Status-Server packets sent to an "accounting" port with an Accounting-Response packet ✨.
Some server implementations accept both Access-Request and Accounting-Request packets on the same port, and they don't distinguish between "authentication only" ports and "accounting only" ports 🌈. Those implementations SHOULD reply to Status-Server packets with an Access-Accept packet 🦋.
The server MAY increment packet counters as a result of receiving a Status-Server packet or sending a Response packet 📊. The server SHOULD NOT perform any other action that is normally performed when it receives a Request packet, other than sending a Response packet 🙅♀️.
4.3. Failover with Status-Server 🔁
A client may wish to "failover" from one proxy to another if it doesn't get a response to an Access-Request or Accounting-Request 🏃♀️. To figure out whether the lack of response is due to a problem with the proxy or a downstream server, the client can send periodic Status-Server packets to a proxy after the lack of a response 🕵️♀️.
These packets help the client work out whether the failure was caused by an issue on the path between the client and proxy or the proxy itself, or whether it's happening downstream 🧭.
If no response is received to Status-Server packets, the RADIUS client can initiate failover to another proxy 🚨. By continuing to send Status-Server packets to the original proxy, the RADIUS client can tell when it becomes responsive again 💖.
Once the server has been deemed responsive, normal RADIUS requests may be sent to it again ✨. This determination should be made separately for each server with which the client has a relationship 🔑. The same algorithm SHOULD be used for both authentication and accounting ports 🫶. The client MUST treat each destination (IP, port) combination as a unique server for the purposes of this determination 🧩.
Clients SHOULD use a retransmission mechanism similar to that given in Section 2.2.1 of [RFC5080] 🔁. If a reliable transport is used for RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST be used ⏰.
4.4. Proxy Server Handling of Status-Server 🧚♀️
Many RADIUS servers can act as proxy servers, and can forward requests to another RADIUS server 🛰️. Such servers MUST NOT proxy Status-Server packets 🚫. The purpose of Status-Server as specified here is to let the client check the responsiveness of a server it has a direct relationship with 💅. Proxying Status-Server queries would wipe out any usefulness that might come from implementing support for them 💀.
Proxy servers MAY be configured to respond to Status-Server queries from clients, and they MAY act as clients sending Status-Server queries to other servers 🎀. However, those activities MUST be independent of one another 🫶.
4.5. Limitations of Status-Server 🚧
RADIUS servers are commonly used in an environment where Network Access Identifiers (NAIs) are used as routing identifiers [RFC4282] 🗺️. In this practice, the User-Name attribute is decorated with realm-routing information, commonly in the format of "user@realm" 🎀. Since a particular RADIUS server may act as a proxy for more than one realm, we need to explain how the behavior defined above in Section 4.3 affects realm routing 🧠.
The schematic below demonstrates this scenario 🖼️.
/-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm BThat is, the NAS has relationships with two RADIUS Proxies, P and S 👯♀️. Each RADIUS proxy has relationships with RADIUS servers for both Realm A and Realm B 💕.
In this scenario, the RADIUS proxies can determine if one or both of the RADIUS servers are dead or unreachable 🪦. The NAS can determine if one or both of the RADIUS proxies are dead or unreachable 🔍. There is an additional case to consider, however 🤔.
If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but RADIUS Proxy S can reach that RADIUS server, then the NAS cannot discover this information using the Status-Server queries as outlined above 😤. It would therefore be useful for the NAS to know that Realm A is reachable from RADIUS Proxy S, as it can then route all requests for Realm A to that RADIUS proxy 🙌. Without this knowledge, the client may route requests to RADIUS Proxy P, where they may be discarded or rejected 😩.
To complicate matters, the behavior of RADIUS Proxies P and S in this situation is not well defined 🌀. Some implementations simply fail to respond to the request, and other implementations respond with an Access-Reject 🙃. If the implementation fails to respond, then the NAS cannot distinguish between the RADIUS proxy being down and the next server along the proxy chain being unreachable 🫠.
In the worst case, failures in routing for Realm A may affect users of Realm B 😱. For example, if RADIUS Proxy P can reach Realm B but not Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then active paths exist to handle all RADIUS requests 🛤️. However, depending on the NAS and RADIUS proxy implementation choices, the NAS may not be able to determine to which server requests may be sent in order to maintain network stability 😵💫.
Unfortunately, this problem cannot be solved by using Status-Server requests 😭. A robust solution would involve either a RADIUS routing table for the NAI realms or a RADIUS "destination unreachable" response to authentication requests 🧩. Either solution would not fit into the traditional RADIUS model, and both are therefore outside of the scope of this specification 🚫.
The problem is discussed here in order to define how best to use Status-Server in this situation, rather than to define a new solution 📝.
When a server has responded recently to a request from a client, that client MUST mark the server as "responsive" 💖. In the above case, a RADIUS proxy may be responding to requests destined for Realm A, but not responding to requests destined for Realm B 🤷♀️. The client therefore considers the server to be responsive, as it is receiving responses from the server ✅.
The client will then continue to send requests to the RADIUS proxy for destination Realm B, even though the RADIUS proxy cannot route the requests to that destination 😩. This failure is a known limitation of RADIUS, and can be partially addressed through the use of failover in the RADIUS proxies 🔧.
A more realistic situation than the one outlined above is one in which each RADIUS proxy also has multiple choices of RADIUS servers for a realm, as outlined below 🌟.
/-> RADIUS Proxy P -----> RADIUS Server P
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server SIn this situation, if all participants implement Status-Server as defined herein, any one link may be broken, and all requests from the NAS will still reach a RADIUS server 🫶. If two links are broken at different places (i.e., not both links from the NAS), then all requests from the NAS will still reach a RADIUS server ✨. In many situations where three or more links are broken, requests from the NAS may still reach a RADIUS server 🌈.
It is RECOMMENDED, therefore, that implementations desiring the most benefit from Status-Server also implement server failover 👑. The combination of these two practices will maximize network reliability and stability 💜.
4.6. Management Information Base (MIB) Considerations 🧚♀️
4.6.1. Interaction with RADIUS Server MIB Modules 📚✨
okay so, Status-Server packets get sent to the RADIUS ports, which means they can mess with the [RFC4669] and [RFC4671] RADIUS server MIB modules 👀. [RFC4669] has a counter called radiusAuthServTotalUnknownTypes that counts "The number of RADIUS packets of unknown type that were received" 💅. [RFC4671] has a similar one called radiusAccServTotalUnknownTypes 🧚.
implementations that don't support Status-Server, or that are set up to ignore Status-Server packets, MUST use these counters to track the Status-Server packets they get 🫶. that's the rule 📏.
BUT if Status-Server is supported and the server is set up to respond the way described above, then the counters in [RFC4669] and [RFC4671] MUST NOT be used to track Status-Server requests or the responses to them 🙈. like, when a server fully implements Status-Server, those counters MUST be unaffected by sending or receiving anything related to Status-Server 🛑✨. no double counting, bestie 💖.
and if a server supports Status-Server AND the [RFC4669] or [RFC4671] MIB modules, it SHOULD also support vendor-specific MIB extensions that are dedicated only to tracking Status-Server requests and responses 🎀. defining the server MIB modules for Status-Server is outside the scope of this document, so that's a whole other story 🌸.
4.6.2. Interaction with RADIUS Client MIB Modules 🦋
Clients that implement Status-Server MUST NOT increment the [RFC4668] or [RFC4670] counters when they receive Response packets to Status-Server queries 💅. again, when a server fully implements Status-Server, those counters MUST be unaffected by sending or receiving packets related to Status-Server 🙅♀️✨. keep the lanes separate, babe 🛣️.
if an implementation supports Status-Server AND the [RFC4668] or [RFC4670] MIB modules, it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses 🌈. and defining the client MIB modules for Status-Server? also outside the scope of this doc 🙈💜.
5. Table of Attributes 🧾💖
okay this table is basically your cheat sheet for which attributes can show up in Status-Server packets, and how many of each 🤓. anything that isn't listed below SHOULD NOT be found in a Status-Server packet 🚫.
Status- Access- Accounting-
Server Accept Response # Attribute
0 0 0 1 User-Name
0 0 0 2 User-Password
0 0 0 3 CHAP-Password
0-1 0 0 4 NAS-IP-Address (Note 1)
0 0+ 0 18 Reply-Message
0+ 0+ 0+ 26 Vendor-Specific
0-1 0 0 32 NAS-Identifier (Note 1)
0 0 0 79 EAP-Message
1 0-1 0-1 80 Message-Authenticator
0-1 0 0 95 NAS-IPv6-Address (Note 1)
0 0 0 103-121 Digest-*
Note 1: A Status-Server packet SHOULD contain one of
(NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both
NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).and this next bit tells you what the entries in that table actually mean 🔍✨.
0 This attribute MUST NOT be present in packet.
0+ Zero or more instances of this attribute MAY be present in
packet.
0-1 Zero or one instance of this attribute MAY be present in
packet.
1 Exactly one instance of this attribute MUST be present in
packet.6. Examples 🌸📦
these examples show how packets flow to both the authentication and accounting ports 🛫. they're not exhaustive, so yes, a bunch more are possible 🫶. the hex dumps are in network byte order, and they use the shared secret "xyzzy5461" 🔐.
6.1. Minimal Query to Authentication Port 🔑
the NAS sends a minimal Status-Server UDP packet to a RADIUS server on port 1812 📨.
the Request Authenticator is a 16-octet random number that the NAS generates 🎲. Message-Authenticator is included so the server can confirm the request came from a known client 🕵️♀️✨.
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
82 20 97 c8 4f a3
1 Code = Status-Server (12)
1 ID = 218
2 Length = 38
16 Request Authenticator
Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3the Response Authenticator is a 16-octet MD5 checksum of the Code (2), ID (218), Length (20), the Request Authenticator from above, and the shared secret 🧮.
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
b5 41 1d 66
1 Code = Access-Accept (2)
1 ID = 218
2 Length = 20
16 Request Authenticator
Attributes:
None.6.2. Minimal Query to Accounting Port 📊
the NAS sends a minimal Status-Server UDP packet to a RADIUS server on port 1813 🚀.
the Request Authenticator is a 16-octet random number generated by the NAS 🎰. Message-Authenticator is included to authenticate that the request came from a known client 🥹.
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
da de 26 36 78 58
1 Code = Status-Server (12)
1 ID = 179
2 Length = 38
16 Request Authenticator
Attributes:
18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858the Response Authenticator is a 16-octet MD5 checksum of the Code (5), ID (179), Length (20), the Request Authenticator from above, and the shared secret 🔏.
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
48 60 66 9c
1 Code = Accounting-Response (5)
1 ID = 179
2 Length = 20
16 Request Authenticator
Attributes:
None.6.3. Verbose Query and Response 🗣️💬
the NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS server on port 1812 🏠➡️🖥️.
the Request Authenticator is a 16-octet random number generated by the NAS 🎲✨.
0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13
f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec
61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
1 Code = Status-Server (12)
1 ID = 71
2 Length = 44
16 Request Authenticator
Attributes:
6 NAS-IP-Address (4) = 192.0.2.16
18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2the Response Authenticator is a 16-octet MD5 checksum of the Code (2), ID (71), Length (52), the Request Authenticator from above, the attributes in this reply, and the shared secret 🧁.
the Reply-Message is "RADIUS Server up 2 days, 18:40" 🎉.
02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd
6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72
76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31
38 3a 34 30
1 Code = Access-Accept (2)
1 ID = 71
2 Length = 52
16 Request Authenticator
Attributes:
32 Reply-Message (18)7. Security Considerations 🔒🚨
this section is SERIOUS, bestie. no cap 😭🔥
this doc basically treats the Status-Server packet like the Access-Request packet 🧠, so it's stuck with the same security considerations from [RFC2865], Section 8 🕸️. Status-Server packets also use the Message-Authenticator attribute, which means they get the same security considerations as [RFC3579], Section 4 🛡️.
we're saying it AGAIN: Status-Server packets MUST contain a Message-Authenticator attribute 📣💅. early implementations that supported Status-Server didn't enforce this, and they were vulnerable to these attacks 😬:
- servers that didn't check the Message-Authenticator attribute could respond to Status-Server packets from an attacker, which could enable a reflected DoS attack onto a real client 💀.
- servers that didn't check the Message-Authenticator attribute could also be hit by a race condition. an attacker could spot an Access-Request packet from a valid client and make a Status-Server packet with the same Request Authenticator 👀. if the attacker won the race against the valid client, the server could reply with an Access-Accept and maybe authorize service it shouldn't 🙈🚫.
the last attack is kinda similar to a related one where Access-Request packets have a CHAP-Password but no Message-Authenticator 🤏. we're repeating the suggestion from [RFC5080], Section 2.2.2 🔁: all clients should send a Message-Authenticator in every Access-Request packet, and all servers should have a configuration setting that decides whether a Message-Authenticator attribute is required in every Access-Request packet or not ⚙️✨.
not including a Message-Authenticator attribute in a Status-Server packet means any RADIUS client or server could be vulnerable to the attacks above 😱. for this reason, implementations of this spec that fail to require the Message-Authenticator attribute are NOT RECOMMENDED 🙅♀️💔.
where this doc differs from [RFC2865] is that it adds a brand new request/response method to RADIUS: the Status-Server request 🆕. since this use is based on standards that were already described and implemented, we don't know of any extra security considerations from using Status-Server the way it's defined here 🧘♀️🌷.
attacks on cryptographic hashes are well known [RFC4270] and they keep getting better over time 📈. RADIUS uses the MD5 hash [RFC1321] for packet authentication and attribute obfuscation 🧂. there are ongoing efforts in the IETF to analyze and address these issues for the RADIUS protocol 🛠️🫶.
8. 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", BCP 14, RFC 2119, March 1997. 🔑
- [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 📡
- [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003. 🚢
- [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 🎲
- [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005. 🪪
- [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007. 🛠️
✨ more coming up in the next part, bestie ✨ 🦄
8.2. Informative References ✨
Okay, now the bonus reading list 📚 These references aren't required to implement this stuff, but they're super helpful background, bestie.
[RFC2866]Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 🧾[RFC3579]Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003. 🔐[RFC4270]Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005. 🧪[RFC4668]Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006. 🦋[RFC4669]Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006. 🌸[RFC4670]Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006. 💜[RFC4671]Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006. ⭐
Acknowledgments ✨
Okay, big shoutouts time 🫶 Parts of the text in Section 3 that define the Request and Response Authenticators were taken, with minor edits, from [RFC2865], Section 3. So that's where a chunk of that wording came from, iykyk. 💖
The author would like to thank Mike McCauley of Open Systems Consultants for making a Radiator server available for interoperability testing. Literally the best kind of help, because testing against another server is how you find out what actually works in the real world 🎀
Ignacio Goyret provided valuable feedback on the history and security of the Status-Server packet. The security part is a big deal, so this one gets a 👑 from me.
Author's Address
Alan DeKok 🧑💻 The FreeRADIUS Server Project http://freeradius.org
EMail: aland@freeradius.org 💌
And that's the whole thing, bestie! 🧚 You made it through all six parts. Main character energy, honestly. 💅✨
📦 where this page comes from
- ietf: rfc5997 2010-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms