idnits 2.17.1 draft-ietf-radext-status-server-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (16 February 2010) is 5176 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alan DeKok 3 INTERNET-DRAFT FreeRADIUS 4 Category: Informational 5 6 Expires: August 16, 2010 7 16 February 2010 9 Use of Status-Server Packets in the 10 Remote Authentication Dial In User Service (RADIUS) Protocol 11 draft-ietf-radext-status-server-06 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 16, 2010. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info/) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Abstract 65 This document describes a deployed extension to the Remote 66 Authentication Dial In User Service (RADIUS) protocol, enabling 67 clients to query the status of a RADIUS server. This extension 68 utilizes the Status-Server (12) Code, which was reserved for 69 experimental use in RFC 2865. 71 Table of Contents 73 1. Introduction ............................................. 4 74 1.1. Applicability ....................................... 4 75 1.2. Terminology ......................................... 5 76 1.3. Requirements Language ............................... 5 77 2. Overview ................................................. 6 78 2.1. Why Access-Request is inappropriate ................. 7 79 2.1.1. Recommendation against Access-Request .......... 8 80 2.2. Why Accounting-Request is inappropriate ............. 8 81 2.2.1. Recommendation against Accounting-Request ...... 8 82 3. Packet Format ............................................ 9 83 3.1. Single definition for Status-Server ................. 11 84 4. Implementation notes ..................................... 11 85 4.1. Client Requirements ................................. 12 86 4.2. Server Requirements ................................. 13 87 4.3. Fail-over with Status-Server ........................ 15 88 4.4. Proxy Server handling of Status-Server .............. 16 89 4.5. Limitations of Status-Server ........................ 16 90 4.6. Management Information Base (MIB) Considerations .... 18 91 4.6.1. Interaction with RADIUS Server MIB modules ..... 18 92 4.6.2. Interaction with RADIUS Client MIB modules ..... 19 93 5. Table of Attributes ...................................... 19 94 6. Examples ................................................. 20 95 6.1. Minimal Query to Authentication Port ................ 20 96 6.2. Minimal Query to Accounting Port .................... 21 97 6.3. Verbose Query and Response .......................... 21 98 7. IANA Considerations ...................................... 22 99 8. Security Considerations .................................. 22 100 9. References ............................................... 23 101 9.1. Normative references ................................ 23 102 9.2. Informative references .............................. 23 104 1. Introduction 106 This document specifies a deployed extension to the Remote 107 Authentication Dial In User Service (RADIUS) protocol, enabling 108 clients to query the status of a RADIUS server. While the Status- 109 Server Code (12) was defined as experimental in [RFC2865] Section 3, 110 details of the operation and potential uses of the Code were not 111 provided. 113 As with the core RADIUS protocol, the Status-Server extension is 114 stateless, and queries do not otherwise affect the normal operation 115 of a server, nor do they result in any side effects, other than 116 perhaps incrementing of an internal packet counter. Most of the 117 implementations of this extension have utilized it alongside 118 implementations of RADIUS as defined in [RFC2865], so that this 119 document focuses solely on the use of this extension with UDP 120 transport. 122 The rest of this document is laid out as follows. Section 2 contains 123 the problem statement, and explanations as to why some possible 124 solutions can have unwanted side effects. Section 3 defines the 125 Status-Server packet format. Section 4 contains client and server 126 requirements, along with some implementation notes. Section 5 lists 127 additional considerations not covered in the other sections. The 128 remaining text contains a RADIUS table of attributes, and discusses 129 security considerations not covered elsewhere in the document. 131 1.1. Applicability 133 This protocol is being recommended for publication as an 134 Informational RFC rather than as a standards-track RFC because of 135 problems with deployed implementations. This includes security 136 vulnerabilities. The fixes recommended here are compatible with 137 existing servers that receive Status-Server packets, but impose new 138 security requirements on clients that send Status-Server packets. 140 Some existing implementations of this protocol do not support the 141 Message-Authenticator attribute. This enables an unauthorized client 142 to spoofing Status-Server packets, potentially leading to incorrect 143 Access-Accepts. In order to remedy this problem, this specification 144 requires the use of the Message-Authenticator attribute to provide 145 per-packet authentication and integrity protection. 147 With existing implementations of this protocol, the potential exists 148 for Status-Server requests to be in conflict with Access-Request or 149 Accounting-Requests packets using the same Identifier. This 150 specification recommends techniques to avoid this problem. 152 These limitations are discussed in more detail below. 154 1.2. Terminology 156 This document uses the following terms: 158 Network Access Server (NAS) 159 The device providing access to the network. Also known as the 160 Authenticator (in IEEE 802.1X terminology) or RADIUS client. 162 RADIUS Proxy 163 In order to provide for the routing of RADIUS authentication and 164 accounting requests, a RADIUS proxy can be employed. To the NAS, 165 the RADIUS proxy appears to act as a RADIUS server, and to the 166 RADIUS server, the proxy appears to act as a RADIUS client. 168 silently discard 169 This means the implementation discards the packet without further 170 processing. The implementation MAY provide the capability of 171 logging the error, including the contents of the silently discarded 172 packet, and SHOULD record the event in a statistics counter. 174 1.3. Requirements Language 176 In this document, several words are used to signify the requirements 177 of the specification. The key words "MUST", "MUST NOT", "REQUIRED", 178 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 179 and "OPTIONAL" in this document are to be interpreted as described in 180 [RFC2119]. 182 2. Overview 184 Status-Server packets are sent by a RADIUS client to a RADIUS server 185 in order to test the status of that server. A Message-Authenticator 186 attribute MUST be included so as to provide per-packet authentication 187 and integrity protection. A single Status-Server packet MUST be 188 included within a UDP datagram. RADIUS proxies MUST NOT forward 189 Status-Server packets. 191 Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy 192 or server, the destination of a Status-Server packet is set to the IP 193 address of the server which is being tested. As a result, the client 194 is provided with an indication of the status of that server only, 195 since no RADIUS proxies are on the path between the RADIUS client and 196 server. Since servers respond to a Status-Server packet without 197 examining the User-Name attribute, the response to a Status-Server 198 packet cannot be used to infer any information about the reachability 199 of specific realms. 201 A RADIUS server or proxy implementing this specification SHOULD 202 respond to a Status-Server packet with an Access-Accept 203 (authentication port) or Accounting-Message (accounting port). An 204 Access-Challenge response is NOT RECOMMENDED. An Access-Reject 205 response MAY be used. The list of attributes that are permitted in 206 Status-Server and Access-Accept packets responding to Status-Server 207 packets are provided in the Section 6. 209 The "hop by hop" functionality of Status-Server packets is useful to 210 RADIUS clients attempting to determine the status of elements on the 211 path between the client and a server. Since the Status-Server packet 212 is non-forwardable, lack of a response may only be due to packet loss 213 or the failure of the server in the destination IP address, not due 214 to faults in downstream links, proxies or servers. It therefore 215 provides an unambiguous indication of the status of a server. 217 This information may be useful in situations where the RADIUS client 218 does not receive a response to an Access-Request. A client may have 219 multiple proxies configured, with one proxy marked as primary and 220 another marked as secondary. If the client does not receive a 221 response to a request sent to the primary proxy, it can "fail over" 222 to the secondary, and send requests to the secondary instead of to 223 the primary proxy. 225 However, it is possible that the lack of a response to requests sent 226 to the primary proxy was due not to a failure within the the primary, 227 but to alternative causes such as a failed link along the path to the 228 destination server, or the failure of the destination server. 230 In such a situation, it may be useful for the client to be able to 231 distinguish between failure causes so that it does not trigger 232 failover inappropriately. For example, if the primary proxy is down, 233 then a quick failover to the secondary proxy would be prudent. 234 Whereas if a downstream failure is the cause, then the value of 235 failover to a secondary proxy will depend on whether packets 236 forwarded by the secondary will utilize independent links, 237 intermediaries or destination servers. 239 The Status-Server packet is not a "Keep-Alive" as discussed in 240 [RFC2865] Section 2.6. "Keep-Alives" are Access-Request packets sent 241 to determine whether a downstream server is responsive. These 242 packets are typically sent only when a server is suspected to be 243 down, and are no longer sent as soon as the server is available 244 again. 246 2.1. Why Access-Request is inappropriate 248 One possible solution to the problem of querying server status is for 249 a NAS to send specially formed Access-Request packets to a RADIUS 250 server's authentication port. The NAS can then look for a response, 251 and use this information to determine if the server is active or 252 unresponsive. 254 However, the server may see the request as a normal login request for 255 a user, and conclude that a real user has logged onto that NAS. The 256 server may then perform actions that are undesirable for a simple 257 status query. The server may alternatively respond with an Access- 258 Challenge, indicating that it believes an extended authentication 259 conversation is necessary. 261 Another possibility is that the server responds with an Access- 262 Reject, indicating that the user is not authorized to gain access to 263 the network. As above, the server may also perform local site 264 actions, such as warning an administrator of failed login attempts. 265 The server may also delay the Access-Reject response, in the 266 traditional manner of rate-limiting failed authentication attempts. 267 This delay in response means that the querying administrator is 268 unsure as to whether or not the server is down, is slow to respond, 269 or is intentionally delaying its response to the query. 271 In addition, using Access-Request queries may mean that the server 272 may have local users configured whose sole reason for existence is to 273 enable these query requests. Unless the server's policy is designed 274 carefully, it may be possible for an attacker to use those 275 credentials to gain unauthorized network access. 277 We note that some NAS implementations currently use Access-Request 278 packets as described above, with a fixed (and non configurable) user 279 name and password. Implementation issues with that equipment means 280 that if a RADIUS server does not respond to those queries, it may be 281 marked as unresponsive by the NAS. This marking may happen even if 282 the server is actively responding to other Access-Requests from that 283 same NAS. This behavior is confusing to administrators who then need 284 to determine why an active server has been marked as "unresponsive". 286 2.1.1. Recommendation against Access-Request 288 For the reasons outlined above, NAS implementors SHOULD NOT generate 289 Access-Request packets solely to see if a server is alive. 290 Similarly, site administrators SHOULD NOT configure test users whose 291 sole reason for existence is to enable such queries via Access- 292 Request packets. 294 Note that it still may be useful to configure test users for the 295 purpose of performing end-to-end or in-depth testing of a servers 296 policy. While this practice is widespread, we caution administrators 297 to use it with care. 299 2.2. Why Accounting-Request is inappropriate 301 A similar solution for the problem of querying server status may be 302 for a NAS to send specially formed Accounting-Request packets to a 303 RADIUS servers accounting port. The NAS can then look for a 304 response, and use this information to determine if the server is 305 active or unresponsive. 307 As seen above with Access-Request, the server may then conclude that 308 a real user has logged onto a NAS, and perform local site actions 309 that are undesirable for a simple status query. 311 Another consideration is that some attributes are mandatory to 312 include in an Accounting-Request. This requirement forces the 313 administrator to query an accounting server with fake values for 314 those attributes in a test packet. These fake values increase the 315 work required to perform a simple query, and may pollute the server's 316 accounting database with incorrect data. 318 2.2.1. Recommendation against Accounting-Request 320 For the reasons outlined above, NAS implementors SHOULD NOT generate 321 Accounting-Request packets solely to see if a server is alive. 322 Similarly, site administrators SHOULD NOT configure accounting 323 policies whose sole reason for existence is to enable such queries 324 via Accounting-Request packets. 326 Note that it still may be useful to configure test users for the 327 purpose of performing end-to-end or in-depth testing of a servers 328 policy. While this practice is widespread, we caution administrators 329 to use it with care. 331 3. Packet Format 333 Status-Server packets reuse the RADIUS packet format, with the fields 334 and values for those fields as defined [RFC2865] Section 3. We do 335 not include all of the text or diagrams of that section here, but 336 instead explain the differences required to implement Status-Server. 338 The Authenticator field of Status-Server packets MUST be generated 339 using the same method as that used for the Request Authenticator 340 field of Access-Request packets, as given below. 342 The role of the Identifier field is the same for Status-Server as for 343 other packets. However, as Status-Server is taking the role of 344 Access-Request or Accounting-Request packets, there is the potential 345 for Status-Server requests to be in conflict with Access-Request or 346 Accounting-Request packets with the same Identifier. In Section 4.2, 347 below, we describe a method for avoiding these problems. This method 348 MUST be used to avoid conflicts between Status-Server and other 349 packet types. 351 Request Authenticator 353 In Status-Server Packets, the Authenticator value is a 16 octet 354 random number, called the Request Authenticator. The value 355 SHOULD be unpredictable and unique over the lifetime of a 356 secret (the password shared between the client and the RADIUS 357 server), since repetition of a request value in conjunction 358 with the same secret would permit an attacker to reply with a 359 previously intercepted response. Since it is expected that the 360 same secret MAY be used to authenticate with servers in 361 disparate geographic regions, the Request Authenticator field 362 SHOULD exhibit global and temporal uniqueness. 364 The Request Authenticator value in a Status-Server packet 365 SHOULD also be unpredictable, lest an attacker trick a server 366 into responding to a predicted future request, and then use the 367 response to masquerade as that server to a future Status-Server 368 request from a client. 370 Similarly, the Response Authenticator field of an Access-Accept 371 packet sent in response to Status-Server queries MUST be generated 372 using the same method as used for calculating the Response 373 Authenticator of the Access-Accept sent in response to an Access- 374 Request, with the Status-Server Request Authenticator taking the 375 place of the Access-Request Request Authenticator. 377 The Response Authenticator field of an Accounting-Response packet 378 sent in response to Status-Server queries MUST be generated using the 379 same method as used for for calculating the Response Authenticator of 380 the Accounting-Response sent in response to an Accounting-Request, 381 with the Status-Server Request Authenticator taking the place of the 382 Accounting-Request Request Authenticator. 384 Note that when a server responds to a Status-Server request, it MUST 385 NOT send more than one response packet. 387 Response Authenticator 389 The value of the Authenticator field in Access-Accept, or 390 Accounting-Response packets is called the Response 391 Authenticator, and contains a one-way MD5 hash calculated over 392 a stream of octets consisting of: the RADIUS packet, beginning 393 with the Code field, including the Identifier, the Length, the 394 Request Authenticator field from the Status-Server packet, and 395 the response Attributes (if any), followed by the shared 396 secret. That is, ResponseAuth = 397 MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where + 398 denotes concatenation. 400 In addition to the above requirements, all Status-Server packets MUST 401 include a Message-Authenticator attribute. Failure to do so would 402 mean that the packets could be trivially spoofed. 404 Status-Server packets MAY include NAS-Identifier, and one of NAS-IP- 405 Address or NAS-IPv6-Address. These attributes are not necessary for 406 the operation of Status-Server, but may be useful information to a 407 server that receives those packets. 409 Other attributes SHOULD NOT be included in a Status-Server packet, 410 and MUST be ignored if they are included. User authentication 411 credentials such as User-Name, User-Password, CHAP-Password, EAP- 412 Message, etc. MUST NOT appear in a Status-Server packet sent to a 413 RADIUS authentication port. User or NAS accounting attributes such 414 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets, etc. MUST 415 NOT appear in a Status-Server packet sent to a RADIUS accounting 416 port. 418 The Access-Accept MAY contain a Reply-Message or Message- 419 Authenticator attribute. It SHOULD NOT contain other attributes. 420 The Accounting-Response packets sent in response to a Status-Server 421 query SHOULD NOT contain any attributes. As the intent is to 422 implement a simple query instead of user authentication or 423 accounting, there is little reason to include other attributes in 424 either the query or the corresponding response. 426 Examples of Status-Server packet flows are given below in Section 7. 428 3.1. Single definition for Status-Server 430 When sent to a RADIUS accounting port, contents of the Status-Server 431 packets are calculated as described above. That is, even though the 432 packets are being sent to an accounting port, they are not created 433 using the same method as for Accounting-Requests. This difference 434 has a number of benefits. 436 Having a single definition for Status-Server packets is simpler than 437 having different definitions for different destination ports. In 438 addition, if we were to define Status-Server as being similar to 439 Accounting-Request but containing no attributes, then those packets 440 could be trivially forged. 442 We therefore define Status-Server consistently, and vary the response 443 packets depending on the port to which the request is sent. When 444 sent to an authentication port, the response to a Status-Server query 445 is an Access-Accept packet. When sent to an accounting port, the 446 response to a Status-Server query is an Accounting-Response packet. 448 4. Implementation notes 450 There are a number of considerations to take into account when 451 implementing support for Status-Server. This section describes 452 implementation details and requirements for RADIUS clients and 453 servers that support Status-Server. 455 The following text applies to the authentication and accounting 456 ports. We use the generic terms below to simplify the discussion: 458 * Request packet 460 An Access-Request packet sent to an authentication port, or 461 an Accounting-Request packet sent to an accounting port. 463 * Response packet 465 An Access-Accept, Access-Challenge, or Access-Reject packet sent 466 from an authentication port, or an Accounting-Response packet 467 sent from an accounting port. 469 We also refer to "client" as the originator of the Status-Server 470 packet, and "server" as the receiver of that packet, and the 471 originator of the Response packet. 473 Using generic terms to describe the Status-Server conversations is 474 simpler than duplicating the text for authentication and accounting 475 packets. 477 4.1. Client Requirements 479 Clients SHOULD permit administrators to globally enable or disable 480 the generation of Status-Server packets. The default SHOULD be that 481 it is disabled. As it is undesirable to send queries to servers that 482 do not support Status-Server, clients SHOULD also have a per-server 483 configuration indicating whether or not to enable Status-Server for a 484 particular destination. The default SHOULD be that it is disabled. 486 The client SHOULD also have a configurable global timer (Tw) that is 487 used when sending periodic Status-Server queries during server fail- 488 over. The default value SHOULD be 30 seconds, and the value MUST NOT 489 be permitted to be set below 6 seconds. If a response has not been 490 received within the timeout period, the Status-Server packet is 491 deemed to have received no corresponding Response packet, and MUST be 492 discarded. 494 Clients SHOULD use a jitter of +/- 2 seconds when sending periodic 495 Status-Server packets, in order to avoid synchronization. 497 When Status-Server packets are sent from a client, they MUST NOT be 498 retransmitted. Instead, the Identity field MUST be changed every 499 time a packet is transmitted. The old packet should be discarded, 500 and a new Status-Server packet should be generated and sent, with new 501 Identity and Authenticator fields. 503 Clients MUST include the Message-Authenticator attribute in all 504 Status-Server packets. Failure to do so would mean that the packets 505 could be trivially spoofed, leading to potential denial of service 506 (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server 507 packet, except as outlined below in Section 6. As the intent of the 508 packet is a simple status query, there is little reason for any 509 additional attributes to appear in Status-Server packets. 511 The client MAY increment packet counters as a result of sending a 512 Status-Server request, or receiving a Response packet. The client 513 MUST NOT perform any other action that is normally performed when it 514 receives a Response packet, such as permitting a user to have login 515 access to a port. 517 Clients MAY send Status-Server requests to the RADIUS destination 518 ports from the same source port used to send normal Request packets. 519 Other clients MAY choose to send Status-Server requests from a unique 520 source port, that is not used to send Request packets. 522 The above suggestion for a unique source port for Status-Server 523 packets aids in matching responses to requests. Since the response 524 to a Status-Server packet is an Access-Accept or Accounting-Response 525 packet, those responses are indistinguishable from other packets sent 526 in response to a Request packet. Therefore, the best way to 527 distinguish them from other traffic is to have a unique port. 529 A client MAY send a Status-Server packet from a source port also used 530 to send Request packets. In that case, the Identifer field MUST be 531 unique across all outstanding Request packets for that source port, 532 independent of the value of the RADIUS Code field for those 533 outstanding requests. Once the client has either received a response 534 to the Status-Server packet, or has determined that the Status-Server 535 packet has timed out, it may reuse that Identifier in another packet. 537 Robust implementations SHOULD accept any Response packet as a valid 538 response to a Status-Server packet, subject to the validation 539 requirements defined above for the Response Authenticator. The code 540 field of the packet matters less than the fact that a valid, signed, 541 response has been received. 543 That is, prior to accepting the response as valid, the client should 544 check that the Response packet Code field is either Access-Accept (2) 545 or Accounting-Response (5). If the code does not match any of these 546 values, the packet MUST be silently discarded. The client MUST then 547 validate the Response Authenticator via the algorithm given above in 548 Section 3. If the Response Authenticator is not valid, the packet 549 MUST be silently discarded. If the Response Authenticator is valid, 550 then the packet MUST be deemed to be a valid response from the 551 server. 553 If the client instead discarded the response because the packet code 554 did not match what it expected, then it could erroneously discard 555 valid responses from a server, and mark that server as unresponsive. 556 This behavior would affect the stability of a RADIUS network, as 557 responsive servers would erroneously be marked as unresponsive. We 558 therefore recommend that clients should be liberal in what they 559 accept as responses to Status-Server queries. 561 4.2. Server Requirements 563 Servers SHOULD permit administrators to globally enable or disable 564 the acceptance of Status-Server packets. The default SHOULD be that 565 it is enabled. Servers SHOULD also permit adminstrators to enable or 566 disable acceptance of Status-Server packets on a per-client basis. 567 The default SHOULD be that it is enabled. 569 Status-Server packets originating from clients that are not permitted 570 to send the server Request packets MUST be silently discarded. If a 571 server does not support Status-Server packets, or is configured to 572 not respond to them, then it MUST silently discard the packet. 574 We note that [RFC2865] Section 3 defines a number of RADIUS Codes, 575 but does not make statements about which Codes are valid for port 576 1812. In contrast, [RFC2866] Section 3 specifies that only RADIUS 577 Accounting packets are to be sent to port 1813. This specification 578 is compatible with [RFC2865], as it uses a known Code for packets to 579 port 1812. This specification is not compatible with [RFC2866], as 580 it adds a new code (Status-Server) that is valid for port 1812. 581 However, as the category of [RFC2866] is Informational, this conflict 582 is acceptable. 584 Servers SHOULD silently discard Status-Server packets if they 585 determine that a client is sending too many Status-Server requests in 586 a particular time period. The method used by a server to make this 587 determination is implementation-specific, and out of scope for this 588 specification. 590 If a server supports Status-Server packets, and is configured to 591 respond to them, and receives a packet from a known client, it MUST 592 validate the Message-Authenticator attribute as defined in [RFC3579] 593 Section 3.2. Packets failing that validation MUST be silently 594 discarded. 596 Servers SHOULD NOT otherwise discard Status-Server packets if they 597 have recently sent the client a Response packet. The query may have 598 originated from an administrator who does not have access to the 599 Response packet stream, or who is interested in obtaining additional 600 information about the server. 602 The server MAY prioritize the handling of Status-Server packets over 603 the handling of other requests, subject to the rate limiting 604 described above. 606 The server MAY decide to not respond to a Status-Server, depending on 607 local site policy. For example, a server that is running but is 608 unable to perform its normal activities MAY silently discard Status- 609 Server packets. This situation can happen, for example, when a 610 server requires access to a database for normal operation, but the 611 connection to that database is down. Or, it may happen when the 612 accepted load on the server is lower than the offered load. 614 Some server implementations require that Access-Request packets are 615 accepted only on "authentication" ports, (e.g. 1812/udp), and that 616 Accounting-Request packets are accepted only on "accounting" ports 617 (e.g. 1813/udp). Those implementations SHOULD reply to Status-Server 618 packets sent to an "authentication" port with an Access-Accept 619 packet. Those implementations SHOULD reply to Status-Server packets 620 sent to an "accounting" port with an Accounting-Response packet. 622 Some server implementations accept both Access-Request and 623 Accounting-Request packets on the same port, and do not distinguish 624 between "authentication only" ports, and "accounting only" ports. 625 Those implementations SHOULD reply to Status-Server packets with an 626 Access-Accept packet. 628 The server MAY increment packet counters as a result of receiving a 629 Status-Server, or sending a Response packet. The server SHOULD NOT 630 perform any other action that is normally performed when it receives 631 a Request packet, other than sending a Response packet. 633 4.3. Fail-over with Status-Server 635 A client may wish to failover from one proxy to another in the event 636 that it does not receive a response to an Access-Request or 637 Accounting-Request. In order to determine whether the lack of 638 response is due to a problem with the proxy or a downstream server, 639 the client can send periodic Status-Server packets to a proxy after 640 lack of a response. The inter-packet period is Tw, as described in 641 Section 4.1. 643 These packets will help the client determine if the failure was due 644 to an issue on the path between the client and proxy or the proxy 645 itself, or whether the issue is occurring downstream. 647 If no response is received to Status-Server packets, the RADIUS 648 client can initiate failover to another proxy. By continuing to send 649 Status-Server packets to the original proxy at an interval of Tw, the 650 RADIUS client can determine when the original proxy becomes 651 responsive again. 653 Once three time periods have passed where Status-Server packets have 654 been sent and responded to, the server should be deemed responsive 655 and RADIUS requests may sent to it again. This determination should 656 be made separately for each server that the client has a relationship 657 with. The same algorithm should be used for both authentication and 658 accounting ports. The client MUST treat each destination (ip, port) 659 combination as a unique server for the purposes of this 660 determination. 662 The above behavior is modelled after [RFC3539] Section 3.4.1. We 663 note that if a reliable transport is used for RADIUS, then the 664 algorithms specified in [RFC3539] MUST be used in preference to the 665 ones given here. 667 4.4. Proxy Server handling of Status-Server 669 Many RADIUS servers can act as proxy servers, and can forward 670 requests to another RADIUS server. Such servers MUST NOT proxy 671 Status-Server packets. The purpose of Status-Server as specified 672 here is to permit the client to query the responsiveness of a server 673 that it has a direct relationship with. Proxying Status-Server 674 queries would negate any usefulness that may be gained by 675 implementing support for them. 677 Proxy servers MAY be configured to respond to Status-Server queries 678 from clients, and MAY act as clients sending Status-Server queries to 679 other servers. However, those activities MUST be independent of one 680 another. 682 4.5. Limitations of Status-Server 684 RADIUS servers are commonly used in an environment where Network 685 Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. 686 In this practice, the User-Name attribute is decorated with realm 687 routing information, commonly in the format of "user@realm". Since a 688 particular RADIUS server may act as a proxy for more than one realm, 689 we need to explain how the behavior defined above in Section 4.3, 690 above, affects realm routing. 692 The schematic below demonstrates this scenario. 694 /-> RADIUS Proxy P -----> RADIUS Server for Realm A 695 / \ / 696 NAS X 697 \ / \ 698 \-> RADIUS Proxy S -----> RADIUS Server for Realm B 700 That is, the NAS has relationships with two RADIUS Proxies, P and S. 701 Each RADIUS Proxyhas relationships with RADIUS Servers for both Realm 702 A and Realm B. 704 In this scenario, the RADIUS Proxies can determine if one or both of 705 the RADIUS Servers are dead or unreachable. The NAS can determine if 706 one or both of the RADIUS Proxies are dead or unreachable. There is 707 an additional case to consider, however. 709 If RADIUS Proxy P cannot reach the RADIUS Server for Realm A, but the 710 RADIUS Proxy S can reach that RADIUS Server, then the NAS cannot 711 discover this information using the Status-Server queries as outlined 712 above. It would therefore be useful for the NAS to know that Realm A 713 is reachable from RADIUS Proxy S, as it can then route all requests 714 for Realm A to that RADIUS Proxy. Without this knowledge, the client 715 may route requests to RADIUS Proxy P, where they may be discarded or 716 rejected. 718 To complicate matters, the behavior of RADIUS Proxies P and S in this 719 situation is not well defined. Some implementations simply fail to 720 respond to the request, and other implementations respond with an 721 Access-Reject. If the implementation fails to respond, then the NAS 722 cannot distinguish between the RADIUS Proxy being down, or the next 723 server along the proxy chain being unreachable. 725 In the worst case, failures in routing for Realm A may affect users 726 of Realm B. For example, if RADIUS Proxy P can reach Realm B but not 727 Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then 728 active paths exist to handle all RADIUS requests. However, depending 729 on the NAS and RADIUS Proxy implementation choices, the NAS may not 730 be able to determine which server requests may be sent to in order to 731 maintain network stability. 733 This problem cannot, unfortunately be solved by using Status-Server 734 requests. A robust solution would involve either a RADIUS routing 735 table for the NAI realms, or a RADIUS "destination unreachable" 736 response to authentication requests. Either solution would not fit 737 into the traditional RADIUS model, and both are therefore outside of 738 the scope of this specification. 740 The problem is discussed here in order to define how best to use 741 Status-Server in this situation, rather than to define a new 742 solution. 744 When a server has responded recently to a request from a client, that 745 client MUST mark the server as "responsive". In the above case, a 746 RADIUS Proxy may be responding to requests destined for Realm A, but 747 not responding to requests destined for Realm B. The client 748 therefore considers the server to be responsive, as it is receiving 749 responses from the server. 751 The client will then continue to send requests to the RADIUS Proxy 752 for destination Realm B, even though the RADIUS Proxy cannot route 753 the requests to that destination. This failure is a known limitation 754 of RADIUS, and can be partially addressed through the use of failover 755 in the RADIUS Proxies. 757 A more realistic situation than the one outlined above is where each 758 RADIUS Proxy also has multiple choices of RADIUS Servers for a realm, 759 as outlined below. 761 /-> RADIUS Proxy P -----> RADIUS Server P 762 / \ / 763 NAS X 764 \ / \ 765 \-> RADIUS Proxy S -----> RADIUS Server S 767 In this situation, if all participants implement Status-Server as 768 defined herein, any one link may be broken, and all requests from the 769 NAS will still reach a RADIUS Server. If two links are broken at 770 different places, (i.e. not both links from the NAS), then all 771 requests from the NAS will still reach a RADIUS Server. In many 772 situations where three or more links are broken, then requests from 773 the NAS may still reach a RADIUS Server. 775 It is RECOMMENDED, therefore, that implementations desiring the most 776 benefit from Status-Server also implement server failover. The 777 combination of these two practices will maximize network reliability 778 and stability. 780 4.6. Management Information Base (MIB) Considerations 782 4.6.1. Interaction with RADIUS Server MIB modules 784 Since Status-Server packets are sent to the defined RADIUS ports, 785 they can affect the [RFC4669] and [RFC4671] RADIUS server MIB 786 modules. [RFC4669] defines a counter named 787 radiusAuthServTotalUnknownTypes that counts "The number of RADIUS 788 packets of unknown type that were received". [RFC4671] defines a 789 similar counter named radiusAcctServTotalUnknownTypes. 790 Implementations not supporting Status-Server, or implementations that 791 are configured to not respond to Status-Server packets MUST use these 792 counters to track received Status-Server packets. 794 If, however, Status-Server is supported and the server is configured 795 to respond as described above, then the counters defined in [RFC4669] 796 and [RFC4671] MUST NOT be used to track Status-Server requests or 797 responses to those requests. That is, when a server fully implements 798 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST 799 be unaffected by the transmission or reception of packets relating to 800 Status-Server. 802 If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB 803 Modules, then it SHOULD also support vendor-specific MIB extensions 804 dedicated solely to tracking Status-Server requests and responses. 806 Any definition of the server MIB modules for Status-Server is outside 807 of the scope of this document. 809 4.6.2. Interaction with RADIUS Client MIB modules 811 Clients implementing Status-Server MUST NOT increment [RFC4668] or 812 [RFC4670] counters upon reception of Response packets to Status- 813 Server queries. That is, when a server fully implements Status- 814 Server, the counters defined in [RFC4668] and [RFC4670] MUST be 815 unaffected by the transmission or reception of packets relating to 816 Status-Server. 818 If an implementation supports Status-Server and the [RFC4668] or 819 [RFC4670] MIB modules, then it SHOULD also support vendor-specific 820 MIB extensions dedicated solely to tracking Status-Server requests 821 and responses. Any definition of the client MIB module extensions 822 for Status-Server is outside of the scope of this document. 824 5. Table of Attributes 826 The following table provides a guide to which attributes may be found 827 in Status-Server packets, and in what quantity. Attributes other 828 than the ones listed below SHOULD NOT be found in a Status-Server 829 packet. 831 Status- Access- Accounting- 832 Server Accept Response # Attribute 834 0 0 0 1 User-Name, 835 0 0 0 2 User-Password 836 0 0 0 3 CHAP-Password 837 0-1 0 0 4 NAS-IP-Address (Note 1) 838 0 0+ 0 18 Reply-Message 839 0+ 0+ 0+ 26 Vendor-Specific 840 0-1 0 0 32 NAS-Identifier (Note 1) 841 0 0 0 70 EAP-MEssage 842 1 0-1 0-1 80 Message-Authenticator 843 0-1 0 0 95 NAS-IPv6-Address (Note 1) 844 0 0 0 103-121 Digest-* 846 Note 1: A Status-Server SHOULD contain one of (NAS-IP-Address or NAS- 847 IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of 848 (NAS-IP-Address or NAS-IPv6-Address). 850 The following table defines the meaning of the above table entries. 852 0 This attribute MUST NOT be present in packet. 853 0+ Zero or more instances of this attribute MAY be present in packet. 855 0-1 Zero or one instance of this attribute MAY be present in packet. 856 1 Exactly one instance of this attribute MUST be present in packet. 858 6. Examples 860 A few examples are presented to illustrate the flow of packets to 861 both the authentication and accounting ports. These examples are not 862 intended to be exhaustive, many others are possible. Hexadecimal 863 dumps of the example packets are given in network byte order, using 864 the shared secret "xyzzy5461". 866 6.1. Minimal Query to Authentication Port 868 The NAS sends a Status-Server UDP packet with minimal content to a 869 RADIUS server on port 1812. 871 The Request Authenticator is a 16 octet random number generated by 872 the NAS. Message-Authenticator is included in order to authenticate 873 that the request came from a known client. 875 0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 876 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 877 82 20 97 c8 4f a3 879 1 Code = Status-Server (12) 880 1 ID = 218 881 2 Length = 38 882 16 Request Authenticator 884 Attributes: 885 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3 887 The Response Authenticator is a 16 octet MD5 checksum of the code 888 (2), id (218), Length (20), the Request Authenticator from above, and 889 the shared secret. 891 02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 892 b5 41 1d 66 894 1 Code = Access-Accept (2) 895 1 ID = 218 896 2 Length = 20 897 16 Request Authenticator 899 Attributes: 900 None. 902 6.2. Minimal Query to Accounting Port 904 The NAS sends a Status-Server UDP packet with minimal content to a 905 RADIUS server on port 1813. 907 The Request Authenticator is a 16 octet random number generated by 908 the NAS. Message-Authenticator is included in order to authenticate 909 that the request came from a known client. 911 0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 912 ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f 913 da de 26 36 78 58 915 1 Code = Status-Server (12) 916 1 ID = 179 917 2 Length = 38 918 16 Request Authenticator 920 Attributes: 921 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858 923 The Response Authenticator is a 16 octet MD5 checksum of the code 924 (5), id (179), Length (20), the Request Authenticator from above, and 925 the shared secret. 927 02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 928 48 60 66 9c 930 1 Code = Accounting-Response (5) 931 1 ID = 179 932 2 Length = 20 933 16 Request Authenticator 935 Attributes: 936 None. 938 6.3. Verbose Query and Response 940 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS 941 server on port 1812. 943 The Request Authenticator is a 16 octet random number generated by 944 the NAS. 946 0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 947 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 948 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2 949 1 Code = Status-Server (12) 950 1 ID = 71 951 2 Length = 44 952 16 Request Authenticator 954 Attributes: 955 6 NAS-IP-Address (4) = 192.0.2.16 956 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2 958 The Response Authenticator is a 16-octet MD5 checksum of the code 959 (2), id (71), Length (52), the Request Authenticator from above, the 960 attributes in this reply, and the shared secret. 962 The Reply-Message is "RADIUS Server up 2 days, 18:40" 964 02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 965 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 966 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 967 38 3a 34 30 969 1 Code = Access-Accept (2) 970 1 ID = 71 971 2 Length = 52 972 16 Request Authenticator 974 Attributes: 975 32 Reply-Message (18) 977 7. IANA Considerations 979 This specification does not create any new registries, nor does it 980 require assignment of any protocol parameters. 982 8. Security Considerations 984 This document defines the Status-Server packet as being similar in 985 treatment to the Access-Request packet, and is therefore subject to 986 the same security considerations as described in [RFC2865], Section 987 8. Status-Server packets also use the Message-Authenticator 988 attribute, and are therefore subject to the same security 989 considerations as [RFC3579], Section 4. 991 We reiterate that Status-Server packets MUST contain a Message- 992 Authenticator attribute. Early implementations supporting Status- 993 Server did not enforce this requirement, and were vulnerable to the 994 following attacks: 996 * Servers not checking Message-Authenticator could respond to 997 Status-Server packets from an attacker, potentially enabling 998 a reflected DoS attack onto a real client. 1000 * Servers not checking Message-Authenticator could be subject to a 1001 race condition, where an attacker could see an Access-Request 1002 packet from a valid client, and synthesise a Status-Server packet 1003 containing the same Request Authenticator. If the attacker won the 1004 race against the valid client, the server could respond with an 1005 Access-Accept, and potentially authorize unwanted service. 1007 The last attack is similar to a related attack when Access-Request 1008 packets contain a CHAP-Password but no Message-Authenticator. We re- 1009 iterate the suggestion of [RFC5080] Section 2.2.2, which suggests 1010 that all clients send a Message-Authenticator in every Access-Request 1011 packet, and that all servers configurably require that a Message- 1012 Authenticator attribute be used in every Access-Request packet. 1014 Failure to include a Message-Authenticator attribute in a Status- 1015 Server packet means that any RADIUS client or server may be 1016 vulnerable to the attacks outlined above. For this reason, 1017 implementations of this specification which fail to require use of 1018 the Message-Authenticator attribute are NOT RECOMMENDED. 1020 Where this document differs from [RFC2865] is that it defines a new 1021 request/response method in RADIUS; the Status-Server request. As 1022 this use is based on previously described and implemented standards, 1023 we know of no additional security considerations that arise from the 1024 use of Status-Server as defined herein. 1026 9. References 1028 9.1. Normative references 1030 [RFC2865] 1031 Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 1032 Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. 1034 [RFC4282] 1035 Aboba, B., and Beadles, M. at al, "The Network Access Identifier", 1036 RFC 4282, December 2005. 1038 9.2. Informative references 1040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1041 Requirement Levels", RFC 2119, March, 1997. 1043 [RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 1045 [RFC3539] Aboba, B., Wood, J., "Authentication, Authorization, and 1046 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 1048 [RFC3579] Aboba, B., Calhoun, P., "RADIUS (Remote Authentication Dial In 1049 User Service) Support For Extensible Authentication Protocol 1050 (EAP)", RFC 3579, September 2003. 1052 [RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 1053 4668, August 2006. 1055 [RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 1056 4669, August 2006. 1058 [RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, 1059 August 2006. 1061 [RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, 1062 August 2006. 1064 [RFC5080] Nelson, D., DeKok, A, "Common Remote Authentication Dial In 1065 User Service (RADIUS) Implementation Issues and Suggested 1066 Fixes", RFC 5080, December 2007. 1068 Acknowledgments 1070 Parts of the text in Section 3 defining the Request and Response 1071 Authenticators were taken with minor edits from [RFC2865] Section 3. 1073 The author would like to thank Mike McCauley of Open Systems 1074 Consultants for making a Radiator server available for 1075 interoperability testing. 1077 Ignacio Goyret provided valuable feedback on the history and security 1078 of the Status-Server packet. 1080 Authors' Addresses 1082 Alan DeKok 1083 The FreeRADIUS Server Project 1084 http://freeradius.org 1086 Email: aland@freeradius.org