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