7 Internet Engineering Task Force (IETF) A. DeKok
8 Request for Comments: 5997 FreeRADIUS
9 Updates: 2866 August 2010
10 Category: Informational
14 Use of Status-Server Packets in the
15 Remote Authentication Dial In User Service (RADIUS) Protocol
19 This document describes a deployed extension to the Remote
20 Authentication Dial In User Service (RADIUS) protocol, enabling
21 clients to query the status of a RADIUS server. This extension
22 utilizes the Status-Server (12) Code, which was reserved for
23 experimental use in RFC 2865.
27 This document is not an Internet Standards Track specification; it is
28 published for informational purposes.
30 This document is a product of the Internet Engineering Task Force
31 (IETF). It represents the consensus of the IETF community. It has
32 received public review and has been approved for publication by the
33 Internet Engineering Steering Group (IESG). Not all documents
34 approved by the IESG are a candidate for any level of Internet
35 Standard; see Section 2 of RFC 5741.
37 Information about the current status of this document, any errata,
38 and how to provide feedback on it may be obtained at
39 http://www.rfc-editor.org/info/rfc5997.
43 Copyright (c) 2010 IETF Trust and the persons identified as the
44 document authors. All rights reserved.
46 This document is subject to BCP 78 and the IETF Trust's Legal
47 Provisions Relating to IETF Documents
48 (http://trustee.ietf.org/license-info) in effect on the date of
49 publication of this document. Please review these documents
50 carefully, as they describe your rights and restrictions with respect
51 to this document. Code Components extracted from this document must
52 include Simplified BSD License text as described in Section 4.e of
53 the Trust Legal Provisions and are provided without warranty as
54 described in the Simplified BSD License.
58 DeKok Informational [Page 1]
60 RFC 5997 Status-Server Practices August 2010
63 This document may contain material from IETF Documents or IETF
64 Contributions published or made publicly available before November
65 10, 2008. The person(s) controlling the copyright in some of this
66 material may not have granted the IETF Trust the right to allow
67 modifications of such material outside the IETF Standards Process.
68 Without obtaining an adequate license from the person(s) controlling
69 the copyright in such materials, this document may not be modified
70 outside the IETF Standards Process, and derivative works of it may
71 not be created outside the IETF Standards Process, except to format
72 it for publication as an RFC or to translate it into languages other
77 1. Introduction ....................................................3
78 1.1. Applicability ..............................................3
79 1.2. Terminology ................................................4
80 1.3. Requirements Language ......................................4
81 2. Overview ........................................................4
82 2.1. Why Access-Request is Inappropriate ........................6
83 2.1.1. Recommendation against Access-Request ...............7
84 2.2. Why Accounting-Request is Inappropriate ....................7
85 2.2.1. Recommendation against Accounting-Request ...........7
86 3. Packet Format ...................................................8
87 3.1. Single Definition for Status-Server .......................10
88 4. Implementation Notes ...........................................10
89 4.1. Client Requirements .......................................11
90 4.2. Server Requirements .......................................12
91 4.3. Failover with Status-Server ...............................14
92 4.4. Proxy Server Handling of Status-Server ....................14
93 4.5. Limitations of Status-Server ..............................15
94 4.6. Management Information Base (MIB) Considerations ..........17
95 4.6.1. Interaction with RADIUS Server MIB Modules .........17
96 4.6.2. Interaction with RADIUS Client MIB Modules .........17
97 5. Table of Attributes ............................................18
98 6. Examples .......................................................19
99 6.1. Minimal Query to Authentication Port ......................19
100 6.2. Minimal Query to Accounting Port ..........................20
101 6.3. Verbose Query and Response ................................21
102 7. Security Considerations ........................................21
103 8. References .....................................................23
104 8.1. Normative References ......................................23
105 8.2. Informative References ....................................23
106 Acknowledgments ...................................................24
114 DeKok Informational [Page 2]
116 RFC 5997 Status-Server Practices August 2010
121 This document specifies a deployed extension to the Remote
122 Authentication Dial In User Service (RADIUS) protocol, enabling
123 clients to query the status of a RADIUS server. While the Status-
124 Server (12) Code was defined as experimental in [RFC2865], Section 3,
125 details of the operation and potential uses of the Code were not
128 As with the core RADIUS protocol, the Status-Server extension is
129 stateless, and queries do not otherwise affect the normal operation
130 of a server, nor do they result in any side effects, other than
131 perhaps incrementing an internal packet counter. Most of the
132 implementations of this extension have utilized it alongside
133 implementations of RADIUS as defined in [RFC2865], so that this
134 document focuses solely on the use of this extension with UDP
137 The rest of this document is laid out as follows. Section 2 contains
138 the problem statement, and explanations as to why some possible
139 solutions can have unwanted side effects. Section 3 defines the
140 Status-Server packet format. Section 4 contains client and server
141 requirements, along with some implementation notes. Section 5
142 contains a RADIUS table of attributes. The remaining text discusses
143 security considerations not covered elsewhere in the document.
147 This protocol is being recommended for publication as an
148 Informational RFC rather than as a Standards-Track RFC because of
149 problems with deployed implementations. This includes security
150 vulnerabilities. The fixes recommended here are compatible with
151 existing servers that receive Status-Server packets, but impose new
152 security requirements on clients that send Status-Server packets.
154 Some existing implementations of this protocol do not support the
155 Message-Authenticator attribute ([RFC3579]). This enables an
156 unauthorized client to spoof Status-Server packets, potentially
157 leading to incorrect Access-Accepts. In order to remedy this
158 problem, this specification requires the use of the Message-
159 Authenticator attribute to provide per-packet authentication and
160 integrity protection.
162 With existing implementations of this protocol, the potential exists
163 for Status-Server requests to be in conflict with Access-Request or
164 Accounting-Request packets using the same Identifier. This
165 specification recommends techniques to avoid this problem.
170 DeKok Informational [Page 3]
172 RFC 5997 Status-Server Practices August 2010
175 These limitations are discussed in more detail below.
179 This document uses the following terms:
181 "Network Access Server (NAS)"
183 The device providing access to the network. Also known as the
184 Authenticator (in IEEE 802.1X terminology) or RADIUS client.
188 In order to provide for the routing of RADIUS authentication and
189 accounting requests, a RADIUS proxy can be employed. To the NAS,
190 the RADIUS proxy appears to act as a RADIUS server, and to the
191 RADIUS server, the proxy appears to act as a RADIUS client.
195 This means the implementation discards the packet without further
196 processing. The implementation MAY provide the capability of
197 logging the error, including the contents of the silently
198 discarded packet, and SHOULD record the event in a statistics
201 1.3. Requirements Language
203 In this document, several words are used to signify the requirements
204 of the specification. The key words "MUST", "MUST NOT", "REQUIRED",
205 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
206 and "OPTIONAL" in this document are to be interpreted as described in
211 Status-Server packets are sent by a RADIUS client to a RADIUS server
212 in order to test the status of that server. The destination of a
213 Status-Server packet is set to the IP address and port of the server
214 that is being tested. A single Status-Server packet MUST be included
215 within a UDP datagram. A Message-Authenticator attribute MUST be
216 included so as to provide per-packet authentication and integrity
219 RADIUS proxies or servers MUST NOT forward Status-Server packets. A
220 RADIUS server or proxy implementing this specification SHOULD respond
221 to a Status-Server packet with an Access-Accept (authentication port)
222 or Accounting-Response (accounting port). An Access-Challenge
226 DeKok Informational [Page 4]
228 RFC 5997 Status-Server Practices August 2010
231 response is NOT RECOMMENDED. An Access-Reject response MAY be used.
232 The list of attributes that are permitted in Status-Server packets,
233 and in Access-Accept or Accounting-Response packets responding to
234 Status-Server packets, is provided in Section 5. Section 6 provides
237 Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
238 or server, the client is provided with an indication of the status of
239 that server only, since no RADIUS proxies are on the path between the
240 RADIUS client and server. As servers respond to a Status-Server
241 packet without examining the User-Name attribute, the response to a
242 Status-Server packet cannot be used to infer any information about
243 the reachability of specific realms.
245 The "hop-by-hop" functionality of Status-Server packets is useful to
246 RADIUS clients attempting to determine the status of the first
247 element on the path between the client and a server. Since the
248 Status-Server packet is non-forwardable, the lack of a response may
249 only be due to packet loss or the failure of the server at the
250 destination IP address, and not due to faults in downstream links,
251 proxies, or servers. It therefore provides an unambiguous indication
252 of the status of a server.
254 This information may be useful in situations in which the RADIUS
255 client does not receive a response to an Access-Request. A client
256 may have multiple proxies configured, with one proxy marked as
257 primary and another marked as secondary. If the client does not
258 receive a response to a request sent to the primary proxy, it can
259 "failover" to the secondary, and send requests to the secondary proxy
262 However, it is possible that the lack of a response to requests sent
263 to the primary proxy was due not to a failure within the primary, but
264 to alternative causes such as a failed link along the path to the
265 destination server or the failure of the destination server itself.
267 In such a situation, it may be useful for the client to be able to
268 distinguish between failure causes so that it does not trigger
269 failover inappropriately. For example, if the primary proxy is down,
270 then a quick failover to the secondary proxy would be prudent;
271 whereas, if a downstream failure is the cause, then the value of
272 failover to a secondary proxy will depend on whether packets
273 forwarded by the secondary will utilize independent links,
274 intermediaries, or destination servers.
282 DeKok Informational [Page 5]
284 RFC 5997 Status-Server Practices August 2010
287 The Status-Server packet is not a "Keep-Alive" as discussed in
288 [RFC2865], Section 2.6. "Keep-Alives" are Access-Request packets
289 sent to determine whether a downstream server is responsive. These
290 packets are typically sent only when a server is suspected to be
291 down, and they are no longer sent as soon as the server is available
294 2.1. Why Access-Request is Inappropriate
296 One possible solution to the problem of querying server status is for
297 a NAS to send specially formed Access-Request packets to a RADIUS
298 server's authentication port. The NAS can then look for a response
299 and use this information to determine if the server is active or
302 However, the server may see the request as a normal login request for
303 a user and conclude that a real user has logged onto that NAS. The
304 server may then perform actions that are undesirable for a simple
305 status query. The server may alternatively respond with an Access-
306 Challenge, indicating that it believes an extended authentication
307 conversation is necessary.
309 Another possibility is that the server responds with an Access-
310 Reject, indicating that the user is not authorized to gain access to
311 the network. As above, the server may also perform local-site
312 actions, such as warning an administrator of failed login attempts.
313 The server may also delay the Access-Reject response, in the
314 traditional manner of rate-limiting failed authentication attempts.
315 This delay in response means that the querying administrator is
316 unsure as to whether or not the server is down, slow to respond, or
317 intentionally delaying its response to the query.
319 In addition, using Access-Request queries may mean that the server
320 may have local users configured whose sole reason for existence is to
321 enable these query requests. Unless the server policy is designed
322 carefully, it may be possible for an attacker to use those
323 credentials to gain unauthorized network access.
325 We note that some NAS implementations currently use Access-Request
326 packets as described above, with a fixed (and non-configurable) user
327 name and password. Implementation issues with that equipment mean
328 that if a RADIUS server does not respond to those queries, it may be
329 marked as unresponsive by the NAS. This marking may happen even if
330 the server is actively responding to other Access-Requests from that
331 same NAS. This behavior is confusing to administrators who then need
332 to determine why an active server has been marked as "unresponsive".
338 DeKok Informational [Page 6]
340 RFC 5997 Status-Server Practices August 2010
343 2.1.1. Recommendation against Access-Request
345 For the reasons outlined above, NAS implementors SHOULD NOT generate
346 Access-Request packets solely to see if a server is alive.
347 Similarly, site administrators SHOULD NOT configure test users whose
348 sole reason for existence is to enable such queries via Access-
351 Note that it still may be useful to configure test users for the
352 purpose of performing end-to-end or in-depth testing of a server
353 policy. While this practice is widespread, we caution administrators
356 2.2. Why Accounting-Request is Inappropriate
358 A similar solution for the problem of querying server status may be
359 for a NAS to send specially formed Accounting-Request packets to a
360 RADIUS server's accounting port. The NAS can then look for a
361 response and use this information to determine if the server is
362 active or unresponsive.
364 As seen above with Access-Request, the server may then conclude that
365 a real user has logged onto a NAS, and perform local-site actions
366 that are undesirable for a simple status query.
368 Another consideration is that some attributes are mandatory to
369 include in an Accounting-Request. This requirement forces the
370 administrator to query an accounting server with fake values for
371 those attributes in a test packet. These fake values increase the
372 work required to perform a simple query, and they may pollute the
373 server's accounting database with incorrect data.
375 2.2.1. Recommendation against Accounting-Request
377 For the reasons outlined above, NAS implementors SHOULD NOT generate
378 Accounting-Request packets solely to see if a server is alive.
379 Similarly, site administrators SHOULD NOT configure accounting
380 policies whose sole reason for existence is to enable such queries
381 via Accounting-Request packets.
383 Note that it still may be useful to configure test users for the
384 purpose of performing end-to-end or in-depth testing of a server's
385 policy. While this practice is widespread, we caution administrators
394 DeKok Informational [Page 7]
396 RFC 5997 Status-Server Practices August 2010
401 Status-Server packets reuse the RADIUS packet format, with the fields
402 and values for those fields as defined in [RFC2865], Section 3. We
403 do not include all of the text or diagrams of that section here, but
404 instead explain the differences required to implement Status-Server.
406 The Authenticator field of Status-Server packets MUST be generated
407 using the same method as that used for the Request Authenticator
408 field of Access-Request packets, as given below.
410 The role of the Identifier field is the same for Status-Server as for
411 other packets. However, as Status-Server is taking the role of
412 Access-Request or Accounting-Request packets, there is the potential
413 for Status-Server requests to be in conflict with Access-Request or
414 Accounting-Request packets with the same Identifier. In Section 4.2
415 below, we describe a method for avoiding these problems. This method
416 MUST be used to avoid conflicts between Status-Server and other
419 Request Authenticator
421 In Status-Server packets, the Authenticator value is a 16-octet
422 random number called the Request Authenticator. The value
423 SHOULD be unpredictable and unique over the lifetime of a
424 secret (the password shared between the client and the RADIUS
425 server), since repetition of a request value in conjunction
426 with the same secret would permit an attacker to reply with a
427 previously intercepted response. Since it is expected that the
428 same secret MAY be used to authenticate with servers in
429 disparate geographic regions, the Request Authenticator field
430 SHOULD exhibit global and temporal uniqueness. See [RFC4086]
431 for suggestions as to how random numbers may be generated.
433 The Request Authenticator value in a Status-Server packet
434 SHOULD also be unpredictable, lest an attacker trick a server
435 into responding to a predicted future request, and then use the
436 response to masquerade as that server to a future Status-Server
437 request from a client.
439 Similarly, the Response Authenticator field of an Access-Accept
440 packet sent in response to Status-Server queries MUST be generated
441 using the same method as used for calculating the Response
442 Authenticator of the Access-Accept sent in response to an Access-
443 Request, with the Status-Server Request Authenticator taking the
444 place of the Access-Request Request Authenticator.
450 DeKok Informational [Page 8]
452 RFC 5997 Status-Server Practices August 2010
455 The Response Authenticator field of an Accounting-Response packet
456 sent in response to Status-Server queries MUST be generated using the
457 same method as used for calculating the Response Authenticator of the
458 Accounting-Response sent in response to an Accounting-Request, with
459 the Status-Server Request Authenticator taking the place of the
460 Accounting-Request Request Authenticator.
462 Note that when a server responds to a Status-Server request, it MUST
463 NOT send more than one Response packet.
465 Response Authenticator
467 The value of the Authenticator field in Access-Accept or
468 Accounting-Response packets is called the Response
469 Authenticator, and contains a one-way MD5 hash calculated over
470 a stream of octets consisting of: the RADIUS packet, beginning
471 with the Code field, including the Identifier, the Length, the
472 Request Authenticator field from the Status-Server packet, and
473 the response Attributes (if any), followed by the shared
477 MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
479 where + denotes concatenation.
481 In addition to the above requirements, all Status-Server packets MUST
482 include a Message-Authenticator attribute. Failure to do so would
483 mean that the packets could be trivially spoofed.
485 Status-Server packets MAY include NAS-Identifier, and one of
486 NAS-IP-Address or NAS-IPv6-Address. These attributes are not
487 necessary for the operation of Status-Server, but may be useful
488 information to a server that receives those packets.
490 Other attributes SHOULD NOT be included in a Status-Server packet,
491 and MUST be ignored if they are included. User authentication
492 credentials such as User-Name, User-Password, CHAP-Password,
493 EAP-Message MUST NOT appear in a Status-Server packet sent to a
494 RADIUS authentication port. User or NAS accounting attributes such
495 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT
496 appear in a Status-Server packet sent to a RADIUS accounting port.
498 The Access-Accept MAY contain a Reply-Message or Message-
499 Authenticator attribute. It SHOULD NOT contain other attributes.
500 The Accounting-Response packets sent in response to a Status-Server
501 query SHOULD NOT contain any attributes. As the intent is to
506 DeKok Informational [Page 9]
508 RFC 5997 Status-Server Practices August 2010
511 implement a simple query instead of user authentication or
512 accounting, there is little reason to include other attributes in
513 either the query or the corresponding response.
515 Examples of Status-Server packet flows are given below in Section 6.
517 3.1. Single Definition for Status-Server
519 When sent to a RADIUS accounting port, the contents of the Status-
520 Server packets are calculated as described above. That is, even
521 though the packets are being sent to an accounting port, they are not
522 created using the same method as is used for Accounting-Requests.
523 This difference has a number of benefits.
525 Having a single definition for Status-Server packets is simpler than
526 having different definitions for different destination ports. In
527 addition, if we were to define Status-Server as being similar to
528 Accounting-Request but containing no attributes, then those packets
529 could be trivially forged.
531 We therefore define Status-Server consistently, and vary the response
532 packets depending on the port to which the request is sent. When
533 sent to an authentication port, the response to a Status-Server query
534 is an Access-Accept packet. When sent to an accounting port, the
535 response to a Status-Server query is an Accounting-Response packet.
537 4. Implementation Notes
539 There are a number of considerations to take into account when
540 implementing support for Status-Server. This section describes
541 implementation details and requirements for RADIUS clients and
542 servers that support Status-Server.
544 The following text applies to the authentication and accounting
545 ports. We use the generic terms below to simplify the discussion:
549 An Access-Request packet sent to an authentication port or an
550 Accounting-Request packet sent to an accounting port.
554 An Access-Accept, Access-Challenge, or Access-Reject packet
555 sent from an authentication port or an Accounting-Response
556 packet sent from an accounting port.
562 DeKok Informational [Page 10]
564 RFC 5997 Status-Server Practices August 2010
567 We also refer to "client" as the originator of the Status-Server
568 packet, and "server" as the receiver of that packet and the
569 originator of the Response packet.
571 Using generic terms to describe the Status-Server conversations is
572 simpler than duplicating the text for authentication and accounting
575 4.1. Client Requirements
577 Clients SHOULD permit administrators to globally enable or disable
578 the generation of Status-Server packets. The default SHOULD be that
579 it is disabled. As it is undesirable to send queries to servers that
580 do not support Status-Server, clients SHOULD also have a per-server
581 configuration indicating whether or not to enable Status-Server for a
582 particular destination. The default SHOULD be that it is disabled.
584 The client SHOULD use a watchdog timer, such as is defined in Section
585 2.2.1 of [RFC5080], to determine when to send Status-Server packets.
587 When Status-Server packets are sent from a client, they MUST NOT be
588 retransmitted. Instead, the Identity field MUST be changed every
589 time a packet is transmitted. The old packet should be discarded,
590 and a new Status-Server packet should be generated and sent, with new
591 Identity and Authenticator fields.
593 Clients MUST include the Message-Authenticator attribute in all
594 Status-Server packets. Failure to do so would mean that the packets
595 could be trivially spoofed, leading to potential denial-of-service
596 (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server
597 packet, except as outlined below in Section 5. As the intent of the
598 packet is a simple status query, there is little reason for any
599 additional attributes to appear in Status-Server packets.
601 The client MAY increment packet counters as a result of sending a
602 Status-Server request or of receiving a Response packet. The client
603 MUST NOT perform any other action that is normally performed when it
604 receives a Response packet, such as permitting a user to have login
607 Clients MAY send Status-Server requests to the RADIUS destination
608 ports from the same source port used to send normal Request packets.
609 Other clients MAY choose to send Status-Server requests from a unique
610 source port that is not used to send Request packets.
612 The above suggestion for a unique source port for Status-Server
613 packets aids in matching responses to requests. Since the response
614 to a Status-Server packet is an Access-Accept or Accounting-Response
618 DeKok Informational [Page 11]
620 RFC 5997 Status-Server Practices August 2010
623 packet, those responses are indistinguishable from other packets sent
624 in response to a Request packet. Therefore, the best way to
625 distinguish them from other traffic is to have a unique port.
627 A client MAY send a Status-Server packet from a source port also used
628 to send Request packets. In that case, the Identifier field MUST be
629 unique across all outstanding Request packets for that source port,
630 independent of the value of the RADIUS Code field for those
631 outstanding requests. Once the client has either received a response
632 to the Status-Server packet or determined that the Status-Server
633 packet has timed out, it may reuse that Identifier in another packet.
635 Robust implementations SHOULD accept any Response packet as a valid
636 response to a Status-Server packet, subject to the validation
637 requirements defined above for the Response Authenticator. The Code
638 field of the packet matters less than the fact that a valid, signed
639 response has been received.
641 That is, prior to accepting the response as valid, the client should
642 check that the Response packet Code field is either Access-Accept (2)
643 or Accounting-Response (5). If the Code does not match any of these
644 values, the packet MUST be silently discarded. The client MUST then
645 validate the Response Authenticator via the algorithm given above in
646 Section 3. If the Response Authenticator is not valid, the packet
647 MUST be silently discarded. If the Response Authenticator is valid,
648 then the packet MUST be deemed to be a valid response from the
651 If the client instead discarded the response because the packet Code
652 did not match what it expected, then it could erroneously discard
653 valid responses from a server, and mark that server as unresponsive.
654 This behavior would affect the stability of a RADIUS network, as
655 responsive servers would erroneously be marked as unresponsive. We
656 therefore recommend that clients should be liberal in what they
657 accept as responses to Status-Server queries.
659 4.2. Server Requirements
661 Servers SHOULD permit administrators to globally enable or disable
662 the acceptance of Status-Server packets. The default SHOULD be that
663 acceptance is enabled. Servers SHOULD also permit administrators to
664 enable or disable acceptance of Status-Server packets on a per-client
665 basis. The default SHOULD be that acceptance is enabled.
667 Status-Server packets originating from clients that are not permitted
668 to send the server Request packets MUST be silently discarded. If a
669 server does not support Status-Server packets, or is configured not
670 to respond to them, then it MUST silently discard the packet.
674 DeKok Informational [Page 12]
676 RFC 5997 Status-Server Practices August 2010
679 We note that [RFC2865], Section 3, defines a number of RADIUS Codes,
680 but does not make statements about which Codes are valid for
681 port 1812. In contrast, [RFC2866], Section 3, specifies that only
682 RADIUS Accounting packets are to be sent to port 1813. This
683 specification is compatible with [RFC2865], as it uses a known Code
684 for packets to port 1812. This specification is not compatible with
685 [RFC2866], as it adds a new Code (Status-Server) that is valid for
686 port 1812. However, as the category of [RFC2866] is Informational,
687 this conflict is acceptable.
689 Servers SHOULD silently discard Status-Server packets if they
690 determine that a client is sending too many Status-Server requests in
691 a particular time period. The method used by a server to make this
692 determination is implementation specific and out of scope for this
695 If a server supports Status-Server packets, and is configured to
696 respond to them, and receives a packet from a known client, it MUST
697 validate the Message-Authenticator attribute as defined in [RFC3579],
698 Section 3.2. Packets failing that validation MUST be silently
701 Servers SHOULD NOT otherwise discard Status-Server packets if they
702 have recently sent the client a Response packet. The query may have
703 originated from an administrator who does not have access to the
704 Response packet stream or one who is interested in obtaining
705 additional information about the server.
707 The server MAY prioritize the handling of Status-Server packets over
708 the handling of other requests, subject to the rate limiting
711 The server MAY decide not to respond to a Status-Server, depending on
712 local-site policy. For example, a server that is running but is
713 unable to perform its normal activities MAY silently discard Status-
714 Server packets. This situation can happen, for example, when a
715 server requires access to a database for normal operation, but the
716 connection to that database is down. Or, it may happen when the
717 accepted load on the server is lower than the offered load.
719 Some server implementations require that Access-Request packets be
720 accepted only on "authentication" ports (e.g., 1812/udp), and that
721 Accounting-Request packets be accepted only on "accounting" ports
722 (e.g., 1813/udp). Those implementations SHOULD reply to Status-
723 Server packets sent to an "authentication" port with an Access-Accept
724 packet and SHOULD reply to Status-Server packets sent to an
725 "accounting" port with an Accounting-Response packet.
730 DeKok Informational [Page 13]
732 RFC 5997 Status-Server Practices August 2010
735 Some server implementations accept both Access-Request and
736 Accounting-Request packets on the same port, and they do not
737 distinguish between "authentication only" ports and "accounting only"
738 ports. Those implementations SHOULD reply to Status-Server packets
739 with an Access-Accept packet.
741 The server MAY increment packet counters as a result of receiving a
742 Status-Server packet or sending a Response packet. The server SHOULD
743 NOT perform any other action that is normally performed when it
744 receives a Request packet, other than sending a Response packet.
746 4.3. Failover with Status-Server
748 A client may wish to "failover" from one proxy to another in the
749 event that it does not receive a response to an Access-Request or
750 Accounting-Request. In order to determine whether the lack of
751 response is due to a problem with the proxy or a downstream server,
752 the client can send periodic Status-Server packets to a proxy after
753 the lack of a response.
755 These packets will help the client determine if the failure was due
756 to an issue on the path between the client and proxy or the proxy
757 itself, or whether the issue is occurring downstream.
759 If no response is received to Status-Server packets, the RADIUS
760 client can initiate failover to another proxy. By continuing to send
761 Status-Server packets to the original proxy, the RADIUS client can
762 determine when it becomes responsive again.
764 Once the server has been deemed responsive, normal RADIUS requests
765 may be sent to it again. This determination should be made
766 separately for each server with which the client has a relationship.
767 The same algorithm SHOULD be used for both authentication and
768 accounting ports. The client MUST treat each destination (IP, port)
769 combination as a unique server for the purposes of this
772 Clients SHOULD use a retransmission mechanism similar to that given
773 in Section 2.2.1 of [RFC5080]. If a reliable transport is used for
774 RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST
777 4.4. Proxy Server Handling of Status-Server
779 Many RADIUS servers can act as proxy servers, and can forward
780 requests to another RADIUS server. Such servers MUST NOT proxy
781 Status-Server packets. The purpose of Status-Server as specified
782 here is to permit the client to query the responsiveness of a server
786 DeKok Informational [Page 14]
788 RFC 5997 Status-Server Practices August 2010
791 with which it has a direct relationship. Proxying Status-Server
792 queries would negate any usefulness that may be gained by
793 implementing support for them.
795 Proxy servers MAY be configured to respond to Status-Server queries
796 from clients, and they MAY act as clients sending Status-Server
797 queries to other servers. However, those activities MUST be
798 independent of one another.
800 4.5. Limitations of Status-Server
802 RADIUS servers are commonly used in an environment where Network
803 Access Identifiers (NAIs) are used as routing identifiers [RFC4282].
804 In this practice, the User-Name attribute is decorated with realm-
805 routing information, commonly in the format of "user@realm". Since a
806 particular RADIUS server may act as a proxy for more than one realm,
807 we need to explain how the behavior defined above in Section 4.3
808 affects realm routing.
810 The schematic below demonstrates this scenario.
812 /-> RADIUS Proxy P -----> RADIUS Server for Realm A
816 \-> RADIUS Proxy S -----> RADIUS Server for Realm B
818 That is, the NAS has relationships with two RADIUS Proxies, P and S.
819 Each RADIUS proxy has relationships with RADIUS servers for both
822 In this scenario, the RADIUS proxies can determine if one or both of
823 the RADIUS servers are dead or unreachable. The NAS can determine if
824 one or both of the RADIUS proxies are dead or unreachable. There is
825 an additional case to consider, however.
827 If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but
828 RADIUS Proxy S can reach that RADIUS server, then the NAS cannot
829 discover this information using the Status-Server queries as outlined
830 above. It would therefore be useful for the NAS to know that Realm A
831 is reachable from RADIUS Proxy S, as it can then route all requests
832 for Realm A to that RADIUS proxy. Without this knowledge, the client
833 may route requests to RADIUS Proxy P, where they may be discarded or
836 To complicate matters, the behavior of RADIUS Proxies P and S in this
837 situation is not well defined. Some implementations simply fail to
838 respond to the request, and other implementations respond with an
842 DeKok Informational [Page 15]
844 RFC 5997 Status-Server Practices August 2010
847 Access-Reject. If the implementation fails to respond, then the NAS
848 cannot distinguish between the RADIUS proxy being down and the next
849 server along the proxy chain being unreachable.
851 In the worst case, failures in routing for Realm A may affect users
852 of Realm B. For example, if RADIUS Proxy P can reach Realm B but not
853 Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then
854 active paths exist to handle all RADIUS requests. However, depending
855 on the NAS and RADIUS proxy implementation choices, the NAS may not
856 be able to determine to which server requests may be sent in order to
857 maintain network stability.
859 Unfortunately, this problem cannot be solved by using Status-Server
860 requests. A robust solution would involve either a RADIUS routing
861 table for the NAI realms or a RADIUS "destination unreachable"
862 response to authentication requests. Either solution would not fit
863 into the traditional RADIUS model, and both are therefore outside of
864 the scope of this specification.
866 The problem is discussed here in order to define how best to use
867 Status-Server in this situation, rather than to define a new
870 When a server has responded recently to a request from a client, that
871 client MUST mark the server as "responsive". In the above case, a
872 RADIUS proxy may be responding to requests destined for Realm A, but
873 not responding to requests destined for Realm B. The client
874 therefore considers the server to be responsive, as it is receiving
875 responses from the server.
877 The client will then continue to send requests to the RADIUS proxy
878 for destination Realm B, even though the RADIUS proxy cannot route
879 the requests to that destination. This failure is a known limitation
880 of RADIUS, and can be partially addressed through the use of failover
881 in the RADIUS proxies.
883 A more realistic situation than the one outlined above is one in
884 which each RADIUS proxy also has multiple choices of RADIUS servers
885 for a realm, as outlined below.
887 /-> RADIUS Proxy P -----> RADIUS Server P
891 \-> RADIUS Proxy S -----> RADIUS Server S
898 DeKok Informational [Page 16]
900 RFC 5997 Status-Server Practices August 2010
903 In this situation, if all participants implement Status-Server as
904 defined herein, any one link may be broken, and all requests from the
905 NAS will still reach a RADIUS server. If two links are broken at
906 different places (i.e., not both links from the NAS), then all
907 requests from the NAS will still reach a RADIUS server. In many
908 situations where three or more links are broken, requests from the
909 NAS may still reach a RADIUS server.
911 It is RECOMMENDED, therefore, that implementations desiring the most
912 benefit from Status-Server also implement server failover. The
913 combination of these two practices will maximize network reliability
916 4.6. Management Information Base (MIB) Considerations
918 4.6.1. Interaction with RADIUS Server MIB Modules
920 Since Status-Server packets are sent to the defined RADIUS ports,
921 they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
922 modules. [RFC4669] defines a counter named
923 radiusAuthServTotalUnknownTypes that counts "The number of RADIUS
924 packets of unknown type that were received". [RFC4671] defines a
925 similar counter named radiusAccServTotalUnknownTypes.
926 Implementations not supporting Status-Server or implementations that
927 are configured not to respond to Status-Server packets MUST use these
928 counters to track received Status-Server packets.
930 If, however, Status-Server is supported and the server is configured
931 to respond as described above, then the counters defined in [RFC4669]
932 and [RFC4671] MUST NOT be used to track Status-Server requests or
933 responses to those requests. That is, when a server fully implements
934 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST
935 be unaffected by the transmission or reception of packets relating to
938 If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB
939 modules, then it SHOULD also support vendor-specific MIB extensions
940 dedicated solely to tracking Status-Server requests and responses.
941 Any definition of the server MIB modules for Status-Server is outside
942 of the scope of this document.
944 4.6.2. Interaction with RADIUS Client MIB Modules
946 Clients implementing Status-Server MUST NOT increment [RFC4668] or
947 [RFC4670] counters upon reception of Response packets to Status-
948 Server queries. That is, when a server fully implements Status-
954 DeKok Informational [Page 17]
956 RFC 5997 Status-Server Practices August 2010
959 Server, the counters defined in [RFC4668] and [RFC4670] MUST be
960 unaffected by the transmission or reception of packets relating to
963 If an implementation supports Status-Server and the [RFC4668] or
964 [RFC4670] MIB modules, then it SHOULD also support vendor-specific
965 MIB extensions dedicated solely to tracking Status-Server requests
966 and responses. Any definition of the client MIB modules for Status-
967 Server is outside of the scope of this document.
969 5. Table of Attributes
971 The following table provides a guide to which attributes may be found
972 in Status-Server packets, and in what quantity. Attributes other
973 than the ones listed below SHOULD NOT be found in a Status-Server
976 Status- Access- Accounting-
977 Server Accept Response # Attribute
980 0 0 0 2 User-Password
981 0 0 0 3 CHAP-Password
982 0-1 0 0 4 NAS-IP-Address (Note 1)
983 0 0+ 0 18 Reply-Message
984 0+ 0+ 0+ 26 Vendor-Specific
985 0-1 0 0 32 NAS-Identifier (Note 1)
987 1 0-1 0-1 80 Message-Authenticator
988 0-1 0 0 95 NAS-IPv6-Address (Note 1)
989 0 0 0 103-121 Digest-*
991 Note 1: A Status-Server packet SHOULD contain one of
992 (NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both
993 NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).
995 The following table defines the meaning of the above table entries.
997 0 This attribute MUST NOT be present in packet.
998 0+ Zero or more instances of this attribute MAY be present in
1000 0-1 Zero or one instance of this attribute MAY be present in
1002 1 Exactly one instance of this attribute MUST be present in
1010 DeKok Informational [Page 18]
1012 RFC 5997 Status-Server Practices August 2010
1017 A few examples are presented to illustrate the flow of packets to
1018 both the authentication and accounting ports. These examples are not
1019 intended to be exhaustive; many others are possible. Hexadecimal
1020 dumps of the example packets are given in network byte order, using
1021 the shared secret "xyzzy5461".
1023 6.1. Minimal Query to Authentication Port
1025 The NAS sends a Status-Server UDP packet with minimal content to a
1026 RADIUS server on port 1812.
1028 The Request Authenticator is a 16-octet random number generated by
1029 the NAS. Message-Authenticator is included in order to authenticate
1030 that the request came from a known client.
1032 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
1033 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
1036 1 Code = Status-Server (12)
1039 16 Request Authenticator
1042 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
1044 The Response Authenticator is a 16-octet MD5 checksum of the Code
1045 (2), ID (218), Length (20), the Request Authenticator from above, and
1048 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
1051 1 Code = Access-Accept (2)
1054 16 Request Authenticator
1066 DeKok Informational [Page 19]
1068 RFC 5997 Status-Server Practices August 2010
1071 6.2. Minimal Query to Accounting Port
1073 The NAS sends a Status-Server UDP packet with minimal content to a
1074 RADIUS server on port 1813.
1076 The Request Authenticator is a 16-octet random number generated by
1077 the NAS. Message-Authenticator is included in order to authenticate
1078 that the request came from a known client.
1080 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
1081 ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
1084 1 Code = Status-Server (12)
1087 16 Request Authenticator
1090 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
1092 The Response Authenticator is a 16-octet MD5 checksum of the Code
1093 (5), ID (179), Length (20), the Request Authenticator from above, and
1096 02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
1099 1 Code = Accounting-Response (5)
1102 16 Request Authenticator
1122 DeKok Informational [Page 20]
1124 RFC 5997 Status-Server Practices August 2010
1127 6.3. Verbose Query and Response
1129 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS
1130 server on port 1812.
1132 The Request Authenticator is a 16-octet random number generated by
1135 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13
1136 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec
1137 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
1139 1 Code = Status-Server (12)
1142 16 Request Authenticator
1145 6 NAS-IP-Address (4) = 192.0.2.16
1146 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
1148 The Response Authenticator is a 16-octet MD5 checksum of the Code
1149 (2), ID (71), Length (52), the Request Authenticator from above, the
1150 attributes in this reply, and the shared secret.
1152 The Reply-Message is "RADIUS Server up 2 days, 18:40"
1154 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd
1155 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72
1156 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31
1159 1 Code = Access-Accept (2)
1162 16 Request Authenticator
1165 32 Reply-Message (18)
1167 7. Security Considerations
1169 This document defines the Status-Server packet as being similar in
1170 treatment to the Access-Request packet, and is therefore subject to
1171 the same security considerations as described in [RFC2865],
1172 Section 8. Status-Server packets also use the Message-Authenticator
1173 attribute, and are therefore subject to the same security
1174 considerations as [RFC3579], Section 4.
1178 DeKok Informational [Page 21]
1180 RFC 5997 Status-Server Practices August 2010
1183 We reiterate that Status-Server packets MUST contain a Message-
1184 Authenticator attribute. Early implementations supporting Status-
1185 Server did not enforce this requirement, and were vulnerable to the
1188 * Servers not checking the Message-Authenticator attribute could
1189 respond to Status-Server packets from an attacker, potentially
1190 enabling a reflected DoS attack onto a real client.
1192 * Servers not checking the Message-Authenticator attribute could
1193 be subject to a race condition, where an attacker could see an
1194 Access-Request packet from a valid client and synthesize a
1195 Status-Server packet containing the same Request Authenticator.
1196 If the attacker won the race against the valid client, the
1197 server could respond with an Access-Accept and potentially
1198 authorize unwanted service.
1200 The last attack is similar to a related attack when Access-Request
1201 packets contain a CHAP-Password but no Message-Authenticator. We
1202 re-iterate the suggestion of [RFC5080], Section 2.2.2, which proposes
1203 that all clients send a Message-Authenticator in every Access-Request
1204 packet, and that all servers have a configuration setting to require
1205 (or not) that a Message-Authenticator attribute be used in every
1206 Access-Request packet.
1208 Failure to include a Message-Authenticator attribute in a Status-
1209 Server packet means that any RADIUS client or server may be
1210 vulnerable to the attacks outlined above. For this reason,
1211 implementations of this specification that fail to require use of the
1212 Message-Authenticator attribute are NOT RECOMMENDED.
1214 Where this document differs from [RFC2865] is that it defines a new
1215 request/response method in RADIUS: the Status-Server request. As
1216 this use is based on previously described and implemented standards,
1217 we know of no additional security considerations that arise from the
1218 use of Status-Server as defined herein.
1220 Attacks on cryptographic hashes are well known [RFC4270] and getting
1221 better with time. RADIUS uses the MD5 hash [RFC1321] for packet
1222 authentication and attribute obfuscation. There are ongoing efforts
1223 in the IETF to analyze and address these issues for the RADIUS
1234 DeKok Informational [Page 22]
1236 RFC 5997 Status-Server Practices August 2010
1241 8.1. Normative References
1243 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
1246 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1247 Requirement Levels", BCP 14, RFC 2119, March 1997.
1249 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
1250 "Remote Authentication Dial In User Service (RADIUS)",
1251 RFC 2865, June 2000.
1253 [RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and
1254 Accounting (AAA) Transport Profile", RFC 3539, June 2003.
1256 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
1257 "Randomness Requirements for Security", BCP 106,
1258 RFC 4086, June 2005.
1260 [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
1261 Network Access Identifier", RFC 4282, December 2005.
1263 [RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication
1264 Dial In User Service (RADIUS) Implementation Issues and
1265 Suggested Fixes", RFC 5080, December 2007.
1267 8.2. Informative References
1269 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
1271 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
1272 Dial In User Service) Support For Extensible
1273 Authentication Protocol (EAP)", RFC 3579, September 2003.
1275 [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
1276 Hashes in Internet Protocols", RFC 4270, November 2005.
1278 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6",
1279 RFC 4668, August 2006.
1281 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6",
1282 RFC 4669, August 2006.
1284 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6",
1285 RFC 4670, August 2006.
1290 DeKok Informational [Page 23]
1292 RFC 5997 Status-Server Practices August 2010
1295 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6",
1296 RFC 4671, August 2006.
1300 Parts of the text in Section 3 defining the Request and Response
1301 Authenticators were taken, with minor edits, from [RFC2865],
1304 The author would like to thank Mike McCauley of Open Systems
1305 Consultants for making a Radiator server available for
1306 interoperability testing.
1308 Ignacio Goyret provided valuable feedback on the history and security
1309 of the Status-Server packet.
1314 The FreeRADIUS Server Project
1315 http://freeradius.org
1317 EMail: aland@freeradius.org
1346 DeKok Informational [Page 24]