GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5997

Internet Engineering Task Force (IETF) A. DeKok Request for Comments: 5997 FreeRADIUS Updates: 2866 August 2010 Category: Informational ISSN: 2070-1721

                Use of Status-Server Packets in the
    Remote Authentication Dial In User Service (RADIUS) Protocol

Abstract

 This document describes a deployed extension to the Remote
 Authentication Dial In User Service (RADIUS) protocol, enabling
 clients to query the status of a RADIUS server.  This extension
 utilizes the Status-Server (12) Code, which was reserved for
 experimental use in RFC 2865.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5997.

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

DeKok Informational [Page 1] RFC 5997 Status-Server Practices August 2010

 This document may contain material from IETF Documents or IETF
 Contributions published or made publicly available before November
 10, 2008.  The person(s) controlling the copyright in some of this
 material may not have granted the IETF Trust the right to allow
 modifications of such material outside the IETF Standards Process.
 Without obtaining an adequate license from the person(s) controlling
 the copyright in such materials, this document may not be modified
 outside the IETF Standards Process, and derivative works of it may
 not be created outside the IETF Standards Process, except to format
 it for publication as an RFC or to translate it into languages other
 than English.

Table of Contents

 1. Introduction ....................................................3
    1.1. Applicability ..............................................3
    1.2. Terminology ................................................4
    1.3. Requirements Language ......................................4
 2. Overview ........................................................4
    2.1. Why Access-Request is Inappropriate ........................6
         2.1.1. Recommendation against Access-Request ...............7
    2.2. Why Accounting-Request is Inappropriate ....................7
         2.2.1. Recommendation against Accounting-Request ...........7
 3. Packet Format ...................................................8
    3.1. Single Definition for Status-Server .......................10
 4. Implementation Notes ...........................................10
    4.1. Client Requirements .......................................11
    4.2. Server Requirements .......................................12
    4.3. Failover with Status-Server ...............................14
    4.4. Proxy Server Handling of Status-Server ....................14
    4.5. Limitations of Status-Server ..............................15
    4.6. Management Information Base (MIB) Considerations ..........17
         4.6.1. Interaction with RADIUS Server MIB Modules .........17
         4.6.2. Interaction with RADIUS Client MIB Modules .........17
 5. Table of Attributes ............................................18
 6. Examples .......................................................19
    6.1. Minimal Query to Authentication Port ......................19
    6.2. Minimal Query to Accounting Port ..........................20
    6.3. Verbose Query and Response ................................21
 7. Security Considerations ........................................21
 8. References .....................................................23
    8.1. Normative References ......................................23
    8.2. Informative References ....................................23
 Acknowledgments ...................................................24

DeKok Informational [Page 2] RFC 5997 Status-Server Practices August 2010

1. Introduction

 This document specifies a deployed extension to the Remote
 Authentication Dial In User Service (RADIUS) protocol, enabling
 clients to query the status of a RADIUS server.  While the Status-
 Server (12) Code was defined as experimental in [RFC2865], Section 3,
 details of the operation and potential uses of the Code were not
 provided.
 As with the core RADIUS protocol, the Status-Server extension is
 stateless, and queries do not otherwise affect the normal operation
 of a server, nor do they result in any side effects, other than
 perhaps incrementing an internal packet counter.  Most of the
 implementations of this extension have utilized it alongside
 implementations of RADIUS as defined in [RFC2865], so that this
 document focuses solely on the use of this extension with UDP
 transport.
 The rest of this document is laid out as follows.  Section 2 contains
 the problem statement, and explanations as to why some possible
 solutions can have unwanted side effects.  Section 3 defines the
 Status-Server packet format.  Section 4 contains client and server
 requirements, along with some implementation notes.  Section 5
 contains a RADIUS table of attributes.  The remaining text discusses
 security considerations not covered elsewhere in the document.

1.1. Applicability

 This protocol is being recommended for publication as an
 Informational RFC rather than as a Standards-Track RFC because of
 problems with deployed implementations.  This includes security
 vulnerabilities.  The fixes recommended here are compatible with
 existing servers that receive Status-Server packets, but impose new
 security requirements on clients that send Status-Server packets.
 Some existing implementations of this protocol do not support the
 Message-Authenticator attribute ([RFC3579]).  This enables an
 unauthorized client to spoof Status-Server packets, potentially
 leading to incorrect Access-Accepts.  In order to remedy this
 problem, this specification requires the use of the Message-
 Authenticator attribute to provide per-packet authentication and
 integrity protection.
 With existing implementations of this protocol, the potential exists
 for Status-Server requests to be in conflict with Access-Request or
 Accounting-Request packets using the same Identifier.  This
 specification recommends techniques to avoid this problem.

DeKok Informational [Page 3] RFC 5997 Status-Server Practices August 2010

 These limitations are discussed in more detail below.

1.2. Terminology

 This document uses the following terms:
 "Network Access Server (NAS)"
    The device providing access to the network.  Also known as the
    Authenticator (in IEEE 802.1X terminology) or RADIUS client.
 "RADIUS Proxy"
    In order to provide for the routing of RADIUS authentication and
    accounting requests, a RADIUS proxy can be employed.  To the NAS,
    the RADIUS proxy appears to act as a RADIUS server, and to the
    RADIUS server, the proxy appears to act as a RADIUS client.
 "silently discard"
    This means the implementation discards the packet without further
    processing.  The implementation MAY provide the capability of
    logging the error, including the contents of the silently
    discarded packet, and SHOULD record the event in a statistics
    counter.

1.3. Requirements Language

 In this document, several words are used to signify the requirements
 of the specification.  The key words "MUST", "MUST NOT", "REQUIRED",
 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
 and "OPTIONAL" in this document are to be interpreted as described in
 [RFC2119].

2. Overview

 Status-Server packets are sent by a RADIUS client to a RADIUS server
 in order to test the status of that server.  The destination of a
 Status-Server packet is set to the IP address and port of the server
 that is being tested.  A single Status-Server packet MUST be included
 within a UDP datagram.  A Message-Authenticator attribute MUST be
 included so as to provide per-packet authentication and integrity
 protection.
 RADIUS proxies or servers MUST NOT forward Status-Server packets.  A
 RADIUS server or proxy implementing this specification SHOULD respond
 to a Status-Server packet with an Access-Accept (authentication port)
 or Accounting-Response (accounting port).  An Access-Challenge

DeKok Informational [Page 4] RFC 5997 Status-Server Practices August 2010

 response is NOT RECOMMENDED.  An Access-Reject response MAY be used.
 The list of attributes that are permitted in Status-Server packets,
 and in Access-Accept or Accounting-Response packets responding to
 Status-Server packets, is provided in Section 5.  Section 6 provides
 several examples.
 Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy
 or server, the client is provided with an indication of the status of
 that server only, since no RADIUS proxies are on the path between the
 RADIUS client and server.  As servers respond to a Status-Server
 packet without examining the User-Name attribute, the response to a
 Status-Server packet cannot be used to infer any information about
 the reachability of specific realms.
 The "hop-by-hop" functionality of Status-Server packets is useful to
 RADIUS clients attempting to determine the status of the first
 element on the path between the client and a server.  Since the
 Status-Server packet is non-forwardable, the lack of a response may
 only be due to packet loss or the failure of the server at the
 destination IP address, and not due to faults in downstream links,
 proxies, or servers.  It therefore provides an unambiguous indication
 of the status of a server.
 This information may be useful in situations in which the RADIUS
 client does not receive a response to an Access-Request.  A client
 may have multiple proxies configured, with one proxy marked as
 primary and another marked as secondary.  If the client does not
 receive a response to a request sent to the primary proxy, it can
 "failover" to the secondary, and send requests to the secondary proxy
 instead.
 However, it is possible that the lack of a response to requests sent
 to the primary proxy was due not to a failure within the primary, but
 to alternative causes such as a failed link along the path to the
 destination server or the failure of the destination server itself.
 In such a situation, it may be useful for the client to be able to
 distinguish between failure causes so that it does not trigger
 failover inappropriately.  For example, if the primary proxy is down,
 then a quick failover to the secondary proxy would be prudent;
 whereas, if a downstream failure is the cause, then the value of
 failover to a secondary proxy will depend on whether packets
 forwarded by the secondary will utilize independent links,
 intermediaries, or destination servers.

DeKok Informational [Page 5] RFC 5997 Status-Server Practices August 2010

 The Status-Server packet is not a "Keep-Alive" as discussed in
 [RFC2865], Section 2.6.  "Keep-Alives" are Access-Request packets
 sent to determine whether a downstream server is responsive.  These
 packets are typically sent only when a server is suspected to be
 down, and they are no longer sent as soon as the server is available
 again.

2.1. Why Access-Request is Inappropriate

 One possible solution to the problem of querying server status is for
 a NAS to send specially formed Access-Request packets to a RADIUS
 server's authentication port.  The NAS can then look for a response
 and use this information to determine if the server is active or
 unresponsive.
 However, the server may see the request as a normal login request for
 a user and conclude that a real user has logged onto that NAS.  The
 server may then perform actions that are undesirable for a simple
 status query.  The server may alternatively respond with an Access-
 Challenge, indicating that it believes an extended authentication
 conversation is necessary.
 Another possibility is that the server responds with an Access-
 Reject, indicating that the user is not authorized to gain access to
 the network.  As above, the server may also perform local-site
 actions, such as warning an administrator of failed login attempts.
 The server may also delay the Access-Reject response, in the
 traditional manner of rate-limiting failed authentication attempts.
 This delay in response means that the querying administrator is
 unsure as to whether or not the server is down, slow to respond, or
 intentionally delaying its response to the query.
 In addition, using Access-Request queries may mean that the server
 may have local users configured whose sole reason for existence is to
 enable these query requests.  Unless the server policy is designed
 carefully, it may be possible for an attacker to use those
 credentials to gain unauthorized network access.
 We note that some NAS implementations currently use Access-Request
 packets as described above, with a fixed (and non-configurable) user
 name and password.  Implementation issues with that equipment mean
 that if a RADIUS server does not respond to those queries, it may be
 marked as unresponsive by the NAS.  This marking may happen even if
 the server is actively responding to other Access-Requests from that
 same NAS.  This behavior is confusing to administrators who then need
 to determine why an active server has been marked as "unresponsive".

DeKok Informational [Page 6] RFC 5997 Status-Server Practices August 2010

2.1.1. Recommendation against Access-Request

 For the reasons outlined above, NAS implementors SHOULD NOT generate
 Access-Request packets solely to see if a server is alive.
 Similarly, site administrators SHOULD NOT configure test users whose
 sole reason for existence is to enable such queries via Access-
 Request packets.
 Note that it still may be useful to configure test users for the
 purpose of performing end-to-end or in-depth testing of a server
 policy.  While this practice is widespread, we caution administrators
 to use it with care.

2.2. Why Accounting-Request is Inappropriate

 A similar solution for the problem of querying server status may be
 for a NAS to send specially formed Accounting-Request packets to a
 RADIUS server's accounting port.  The NAS can then look for a
 response and use this information to determine if the server is
 active or unresponsive.
 As seen above with Access-Request, the server may then conclude that
 a real user has logged onto a NAS, and perform local-site actions
 that are undesirable for a simple status query.
 Another consideration is that some attributes are mandatory to
 include in an Accounting-Request.  This requirement forces the
 administrator to query an accounting server with fake values for
 those attributes in a test packet.  These fake values increase the
 work required to perform a simple query, and they may pollute the
 server's accounting database with incorrect data.

2.2.1. Recommendation against Accounting-Request

 For the reasons outlined above, NAS implementors SHOULD NOT generate
 Accounting-Request packets solely to see if a server is alive.
 Similarly, site administrators SHOULD NOT configure accounting
 policies whose sole reason for existence is to enable such queries
 via Accounting-Request packets.
 Note that it still may be useful to configure test users for the
 purpose of performing end-to-end or in-depth testing of a server's
 policy.  While this practice is widespread, we caution administrators
 to use it with care.

DeKok Informational [Page 7] RFC 5997 Status-Server Practices August 2010

3. Packet Format

 Status-Server packets reuse the RADIUS packet format, with the fields
 and values for those fields as defined in [RFC2865], Section 3.  We
 do not include all of the text or diagrams of that section here, but
 instead explain the differences required to implement Status-Server.
 The Authenticator field of Status-Server packets MUST be generated
 using the same method as that used for the Request Authenticator
 field of Access-Request packets, as given below.
 The role of the Identifier field is the same for Status-Server as for
 other packets.  However, as Status-Server is taking the role of
 Access-Request or Accounting-Request packets, there is the potential
 for Status-Server requests to be in conflict with Access-Request or
 Accounting-Request packets with the same Identifier.  In Section 4.2
 below, we describe a method for avoiding these problems.  This method
 MUST be used to avoid conflicts between Status-Server and other
 packet types.
    Request Authenticator
       In Status-Server packets, the Authenticator value is a 16-octet
       random number called the Request Authenticator.  The value
       SHOULD be unpredictable and unique over the lifetime of a
       secret (the password shared between the client and the RADIUS
       server), since repetition of a request value in conjunction
       with the same secret would permit an attacker to reply with a
       previously intercepted response.  Since it is expected that the
       same secret MAY be used to authenticate with servers in
       disparate geographic regions, the Request Authenticator field
       SHOULD exhibit global and temporal uniqueness.  See [RFC4086]
       for suggestions as to how random numbers may be generated.
       The Request Authenticator value in a Status-Server packet
       SHOULD also be unpredictable, lest an attacker trick a server
       into responding to a predicted future request, and then use the
       response to masquerade as that server to a future Status-Server
       request from a client.
 Similarly, the Response Authenticator field of an Access-Accept
 packet sent in response to Status-Server queries MUST be generated
 using the same method as used for calculating the Response
 Authenticator of the Access-Accept sent in response to an Access-
 Request, with the Status-Server Request Authenticator taking the
 place of the Access-Request Request Authenticator.

DeKok Informational [Page 8] RFC 5997 Status-Server Practices August 2010

 The Response Authenticator field of an Accounting-Response packet
 sent in response to Status-Server queries MUST be generated using the
 same method as used for calculating the Response Authenticator of the
 Accounting-Response sent in response to an Accounting-Request, with
 the Status-Server Request Authenticator taking the place of the
 Accounting-Request Request Authenticator.
 Note that when a server responds to a Status-Server request, it MUST
 NOT send more than one Response packet.
    Response Authenticator
       The value of the Authenticator field in Access-Accept or
       Accounting-Response packets is called the Response
       Authenticator, and contains a one-way MD5 hash calculated over
       a stream of octets consisting of: the RADIUS packet, beginning
       with the Code field, including the Identifier, the Length, the
       Request Authenticator field from the Status-Server packet, and
       the response Attributes (if any), followed by the shared
       secret.  That is,
       ResponseAuth =
          MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
       where + denotes concatenation.
 In addition to the above requirements, all Status-Server packets MUST
 include a Message-Authenticator attribute.  Failure to do so would
 mean that the packets could be trivially spoofed.
 Status-Server packets MAY include NAS-Identifier, and one of
 NAS-IP-Address or NAS-IPv6-Address.  These attributes are not
 necessary for the operation of Status-Server, but may be useful
 information to a server that receives those packets.
 Other attributes SHOULD NOT be included in a Status-Server packet,
 and MUST be ignored if they are included.  User authentication
 credentials such as User-Name, User-Password, CHAP-Password,
 EAP-Message MUST NOT appear in a Status-Server packet sent to a
 RADIUS authentication port.  User or NAS accounting attributes such
 as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT
 appear in a Status-Server packet sent to a RADIUS accounting port.
 The Access-Accept MAY contain a Reply-Message or Message-
 Authenticator attribute.  It SHOULD NOT contain other attributes.
 The Accounting-Response packets sent in response to a Status-Server
 query SHOULD NOT contain any attributes.  As the intent is to

DeKok Informational [Page 9] RFC 5997 Status-Server Practices August 2010

 implement a simple query instead of user authentication or
 accounting, there is little reason to include other attributes in
 either the query or the corresponding response.
 Examples of Status-Server packet flows are given below in Section 6.

3.1. Single Definition for Status-Server

 When sent to a RADIUS accounting port, the contents of the Status-
 Server packets are calculated as described above.  That is, even
 though the packets are being sent to an accounting port, they are not
 created using the same method as is used for Accounting-Requests.
 This difference has a number of benefits.
 Having a single definition for Status-Server packets is simpler than
 having different definitions for different destination ports.  In
 addition, if we were to define Status-Server as being similar to
 Accounting-Request but containing no attributes, then those packets
 could be trivially forged.
 We therefore define Status-Server consistently, and vary the response
 packets depending on the port to which the request is sent.  When
 sent to an authentication port, the response to a Status-Server query
 is an Access-Accept packet.  When sent to an accounting port, the
 response to a Status-Server query is an Accounting-Response packet.

4. Implementation Notes

 There are a number of considerations to take into account when
 implementing support for Status-Server.  This section describes
 implementation details and requirements for RADIUS clients and
 servers that support Status-Server.
 The following text applies to the authentication and accounting
 ports.  We use the generic terms below to simplify the discussion:
  • Request packet
       An Access-Request packet sent to an authentication port or an
       Accounting-Request packet sent to an accounting port.
  • Response packet
       An Access-Accept, Access-Challenge, or Access-Reject packet
       sent from an authentication port or an Accounting-Response
       packet sent from an accounting port.

DeKok Informational [Page 10] RFC 5997 Status-Server Practices August 2010

 We also refer to "client" as the originator of the Status-Server
 packet, and "server" as the receiver of that packet and the
 originator of the Response packet.
 Using generic terms to describe the Status-Server conversations is
 simpler than duplicating the text for authentication and accounting
 packets.

4.1. Client Requirements

 Clients SHOULD permit administrators to globally enable or disable
 the generation of Status-Server packets.  The default SHOULD be that
 it is disabled.  As it is undesirable to send queries to servers that
 do not support Status-Server, clients SHOULD also have a per-server
 configuration indicating whether or not to enable Status-Server for a
 particular destination.  The default SHOULD be that it is disabled.
 The client SHOULD use a watchdog timer, such as is defined in Section
 2.2.1 of [RFC5080], to determine when to send Status-Server packets.
 When Status-Server packets are sent from a client, they MUST NOT be
 retransmitted.  Instead, the Identity field MUST be changed every
 time a packet is transmitted.  The old packet should be discarded,
 and a new Status-Server packet should be generated and sent, with new
 Identity and Authenticator fields.
 Clients MUST include the Message-Authenticator attribute in all
 Status-Server packets.  Failure to do so would mean that the packets
 could be trivially spoofed, leading to potential denial-of-service
 (DoS) attacks.  Other attributes SHOULD NOT appear in a Status-Server
 packet, except as outlined below in Section 5.  As the intent of the
 packet is a simple status query, there is little reason for any
 additional attributes to appear in Status-Server packets.
 The client MAY increment packet counters as a result of sending a
 Status-Server request or of receiving a Response packet.  The client
 MUST NOT perform any other action that is normally performed when it
 receives a Response packet, such as permitting a user to have login
 access to a port.
 Clients MAY send Status-Server requests to the RADIUS destination
 ports from the same source port used to send normal Request packets.
 Other clients MAY choose to send Status-Server requests from a unique
 source port that is not used to send Request packets.
 The above suggestion for a unique source port for Status-Server
 packets aids in matching responses to requests.  Since the response
 to a Status-Server packet is an Access-Accept or Accounting-Response

DeKok Informational [Page 11] RFC 5997 Status-Server Practices August 2010

 packet, those responses are indistinguishable from other packets sent
 in response to a Request packet.  Therefore, the best way to
 distinguish them from other traffic is to have a unique port.
 A client MAY send a Status-Server packet from a source port also used
 to send Request packets.  In that case, the Identifier field MUST be
 unique across all outstanding Request packets for that source port,
 independent of the value of the RADIUS Code field for those
 outstanding requests.  Once the client has either received a response
 to the Status-Server packet or determined that the Status-Server
 packet has timed out, it may reuse that Identifier in another packet.
 Robust implementations SHOULD accept any Response packet as a valid
 response to a Status-Server packet, subject to the validation
 requirements defined above for the Response Authenticator.  The Code
 field of the packet matters less than the fact that a valid, signed
 response has been received.
 That is, prior to accepting the response as valid, the client should
 check that the Response packet Code field is either Access-Accept (2)
 or Accounting-Response (5).  If the Code does not match any of these
 values, the packet MUST be silently discarded.  The client MUST then
 validate the Response Authenticator via the algorithm given above in
 Section 3.  If the Response Authenticator is not valid, the packet
 MUST be silently discarded.  If the Response Authenticator is valid,
 then the packet MUST be deemed to be a valid response from the
 server.
 If the client instead discarded the response because the packet Code
 did not match what it expected, then it could erroneously discard
 valid responses from a server, and mark that server as unresponsive.
 This behavior would affect the stability of a RADIUS network, as
 responsive servers would erroneously be marked as unresponsive.  We
 therefore recommend that clients should be liberal in what they
 accept as responses to Status-Server queries.

4.2. Server Requirements

 Servers SHOULD permit administrators to globally enable or disable
 the acceptance of Status-Server packets.  The default SHOULD be that
 acceptance is enabled.  Servers SHOULD also permit administrators to
 enable or disable acceptance of Status-Server packets on a per-client
 basis.  The default SHOULD be that acceptance is enabled.
 Status-Server packets originating from clients that are not permitted
 to send the server Request packets MUST be silently discarded.  If a
 server does not support Status-Server packets, or is configured not
 to respond to them, then it MUST silently discard the packet.

DeKok Informational [Page 12] RFC 5997 Status-Server Practices August 2010

 We note that [RFC2865], Section 3, defines a number of RADIUS Codes,
 but does not make statements about which Codes are valid for
 port 1812.  In contrast, [RFC2866], Section 3, specifies that only
 RADIUS Accounting packets are to be sent to port 1813.  This
 specification is compatible with [RFC2865], as it uses a known Code
 for packets to port 1812.  This specification is not compatible with
 [RFC2866], as it adds a new Code (Status-Server) that is valid for
 port 1812.  However, as the category of [RFC2866] is Informational,
 this conflict is acceptable.
 Servers SHOULD silently discard Status-Server packets if they
 determine that a client is sending too many Status-Server requests in
 a particular time period.  The method used by a server to make this
 determination is implementation specific and out of scope for this
 specification.
 If a server supports Status-Server packets, and is configured to
 respond to them, and receives a packet from a known client, it MUST
 validate the Message-Authenticator attribute as defined in [RFC3579],
 Section 3.2.  Packets failing that validation MUST be silently
 discarded.
 Servers SHOULD NOT otherwise discard Status-Server packets if they
 have recently sent the client a Response packet.  The query may have
 originated from an administrator who does not have access to the
 Response packet stream or one who is interested in obtaining
 additional information about the server.
 The server MAY prioritize the handling of Status-Server packets over
 the handling of other requests, subject to the rate limiting
 described above.
 The server MAY decide not to respond to a Status-Server, depending on
 local-site policy.  For example, a server that is running but is
 unable to perform its normal activities MAY silently discard Status-
 Server packets.  This situation can happen, for example, when a
 server requires access to a database for normal operation, but the
 connection to that database is down.  Or, it may happen when the
 accepted load on the server is lower than the offered load.
 Some server implementations require that Access-Request packets be
 accepted only on "authentication" ports (e.g., 1812/udp), and that
 Accounting-Request packets be accepted only on "accounting" ports
 (e.g., 1813/udp).  Those implementations SHOULD reply to Status-
 Server packets sent to an "authentication" port with an Access-Accept
 packet and SHOULD reply to Status-Server packets sent to an
 "accounting" port with an Accounting-Response packet.

DeKok Informational [Page 13] RFC 5997 Status-Server Practices August 2010

 Some server implementations accept both Access-Request and
 Accounting-Request packets on the same port, and they do not
 distinguish between "authentication only" ports and "accounting only"
 ports.  Those implementations SHOULD reply to Status-Server packets
 with an Access-Accept packet.
 The server MAY increment packet counters as a result of receiving a
 Status-Server packet or sending a Response packet.  The server SHOULD
 NOT perform any other action that is normally performed when it
 receives a Request packet, other than sending a Response packet.

4.3. Failover with Status-Server

 A client may wish to "failover" from one proxy to another in the
 event that it does not receive a response to an Access-Request or
 Accounting-Request.  In order to determine whether the lack of
 response is due to a problem with the proxy or a downstream server,
 the client can send periodic Status-Server packets to a proxy after
 the lack of a response.
 These packets will help the client determine if the failure was due
 to an issue on the path between the client and proxy or the proxy
 itself, or whether the issue is occurring downstream.
 If no response is received to Status-Server packets, the RADIUS
 client can initiate failover to another proxy.  By continuing to send
 Status-Server packets to the original proxy, the RADIUS client can
 determine when it becomes responsive again.
 Once the server has been deemed responsive, normal RADIUS requests
 may be sent to it again.  This determination should be made
 separately for each server with which the client has a relationship.
 The same algorithm SHOULD be used for both authentication and
 accounting ports.  The client MUST treat each destination (IP, port)
 combination as a unique server for the purposes of this
 determination.
 Clients SHOULD use a retransmission mechanism similar to that given
 in Section 2.2.1 of [RFC5080].  If a reliable transport is used for
 RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST
 be used.

4.4. Proxy Server Handling of Status-Server

 Many RADIUS servers can act as proxy servers, and can forward
 requests to another RADIUS server.  Such servers MUST NOT proxy
 Status-Server packets.  The purpose of Status-Server as specified
 here is to permit the client to query the responsiveness of a server

DeKok Informational [Page 14] RFC 5997 Status-Server Practices August 2010

 with which it has a direct relationship.  Proxying Status-Server
 queries would negate any usefulness that may be gained by
 implementing support for them.
 Proxy servers MAY be configured to respond to Status-Server queries
 from clients, and they MAY act as clients sending Status-Server
 queries to other servers.  However, those activities MUST be
 independent of one another.

4.5. Limitations of Status-Server

 RADIUS servers are commonly used in an environment where Network
 Access Identifiers (NAIs) are used as routing identifiers [RFC4282].
 In this practice, the User-Name attribute is decorated with realm-
 routing information, commonly in the format of "user@realm".  Since a
 particular RADIUS server may act as a proxy for more than one realm,
 we need to explain how the behavior defined above in Section 4.3
 affects realm routing.
 The schematic below demonstrates this scenario.
            /-> RADIUS Proxy P -----> RADIUS Server for Realm A
           /                    \ /
        NAS                      X
           \                    / \
            \-> RADIUS Proxy S -----> RADIUS Server for Realm B
 That is, the NAS has relationships with two RADIUS Proxies, P and S.
 Each RADIUS proxy has relationships with RADIUS servers for both
 Realm A and Realm B.
 In this scenario, the RADIUS proxies can determine if one or both of
 the RADIUS servers are dead or unreachable.  The NAS can determine if
 one or both of the RADIUS proxies are dead or unreachable.  There is
 an additional case to consider, however.
 If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but
 RADIUS Proxy S can reach that RADIUS server, then the NAS cannot
 discover this information using the Status-Server queries as outlined
 above.  It would therefore be useful for the NAS to know that Realm A
 is reachable from RADIUS Proxy S, as it can then route all requests
 for Realm A to that RADIUS proxy.  Without this knowledge, the client
 may route requests to RADIUS Proxy P, where they may be discarded or
 rejected.
 To complicate matters, the behavior of RADIUS Proxies P and S in this
 situation is not well defined.  Some implementations simply fail to
 respond to the request, and other implementations respond with an

DeKok Informational [Page 15] RFC 5997 Status-Server Practices August 2010

 Access-Reject.  If the implementation fails to respond, then the NAS
 cannot distinguish between the RADIUS proxy being down and the next
 server along the proxy chain being unreachable.
 In the worst case, failures in routing for Realm A may affect users
 of Realm B.  For example, if RADIUS Proxy P can reach Realm B but not
 Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then
 active paths exist to handle all RADIUS requests.  However, depending
 on the NAS and RADIUS proxy implementation choices, the NAS may not
 be able to determine to which server requests may be sent in order to
 maintain network stability.
 Unfortunately, this problem cannot be solved by using Status-Server
 requests.  A robust solution would involve either a RADIUS routing
 table for the NAI realms or a RADIUS "destination unreachable"
 response to authentication requests.  Either solution would not fit
 into the traditional RADIUS model, and both are therefore outside of
 the scope of this specification.
 The problem is discussed here in order to define how best to use
 Status-Server in this situation, rather than to define a new
 solution.
 When a server has responded recently to a request from a client, that
 client MUST mark the server as "responsive".  In the above case, a
 RADIUS proxy may be responding to requests destined for Realm A, but
 not responding to requests destined for Realm B.  The client
 therefore considers the server to be responsive, as it is receiving
 responses from the server.
 The client will then continue to send requests to the RADIUS proxy
 for destination Realm B, even though the RADIUS proxy cannot route
 the requests to that destination.  This failure is a known limitation
 of RADIUS, and can be partially addressed through the use of failover
 in the RADIUS proxies.
 A more realistic situation than the one outlined above is one in
 which each RADIUS proxy also has multiple choices of RADIUS servers
 for a realm, as outlined below.
              /-> RADIUS Proxy P -----> RADIUS Server P
             /                    \ /
          NAS                      X
             \                    / \
              \-> RADIUS Proxy S -----> RADIUS Server S

DeKok Informational [Page 16] RFC 5997 Status-Server Practices August 2010

 In this situation, if all participants implement Status-Server as
 defined herein, any one link may be broken, and all requests from the
 NAS will still reach a RADIUS server.  If two links are broken at
 different places (i.e., not both links from the NAS), then all
 requests from the NAS will still reach a RADIUS server.  In many
 situations where three or more links are broken, requests from the
 NAS may still reach a RADIUS server.
 It is RECOMMENDED, therefore, that implementations desiring the most
 benefit from Status-Server also implement server failover.  The
 combination of these two practices will maximize network reliability
 and stability.

4.6. Management Information Base (MIB) Considerations

4.6.1. Interaction with RADIUS Server MIB Modules

 Since Status-Server packets are sent to the defined RADIUS ports,
 they can affect the [RFC4669] and [RFC4671] RADIUS server MIB
 modules.  [RFC4669] defines a counter named
 radiusAuthServTotalUnknownTypes that counts "The number of RADIUS
 packets of unknown type that were received".  [RFC4671] defines a
 similar counter named radiusAccServTotalUnknownTypes.
 Implementations not supporting Status-Server or implementations that
 are configured not to respond to Status-Server packets MUST use these
 counters to track received Status-Server packets.
 If, however, Status-Server is supported and the server is configured
 to respond as described above, then the counters defined in [RFC4669]
 and [RFC4671] MUST NOT be used to track Status-Server requests or
 responses to those requests.  That is, when a server fully implements
 Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST
 be unaffected by the transmission or reception of packets relating to
 Status-Server.
 If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB
 modules, then it SHOULD also support vendor-specific MIB extensions
 dedicated solely to tracking Status-Server requests and responses.
 Any definition of the server MIB modules for Status-Server is outside
 of the scope of this document.

4.6.2. Interaction with RADIUS Client MIB Modules

 Clients implementing Status-Server MUST NOT increment [RFC4668] or
 [RFC4670] counters upon reception of Response packets to Status-
 Server queries.  That is, when a server fully implements Status-

DeKok Informational [Page 17] RFC 5997 Status-Server Practices August 2010

 Server, the counters defined in [RFC4668] and [RFC4670] MUST be
 unaffected by the transmission or reception of packets relating to
 Status-Server.
 If an implementation supports Status-Server and the [RFC4668] or
 [RFC4670] MIB modules, then it SHOULD also support vendor-specific
 MIB extensions dedicated solely to tracking Status-Server requests
 and responses.  Any definition of the client MIB modules for Status-
 Server is outside of the scope of this document.

5. Table of Attributes

 The following table provides a guide to which attributes may be found
 in Status-Server packets, and in what quantity.  Attributes other
 than the ones listed below SHOULD NOT be found in a Status-Server
 packet.
    Status-  Access-  Accounting-
    Server   Accept   Response      #      Attribute
    0        0        0             1      User-Name
    0        0        0             2      User-Password
    0        0        0             3      CHAP-Password
    0-1      0        0             4      NAS-IP-Address (Note 1)
    0        0+       0            18      Reply-Message
    0+       0+       0+           26      Vendor-Specific
    0-1      0        0            32      NAS-Identifier (Note 1)
    0        0        0            79      EAP-Message
    1        0-1      0-1          80      Message-Authenticator
    0-1      0        0            95      NAS-IPv6-Address (Note 1)
    0        0        0            103-121 Digest-*
    Note 1: A Status-Server packet SHOULD contain one of
    (NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both
    NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).
 The following table defines the meaning of the above table entries.
 0     This attribute MUST NOT be present in packet.
 0+    Zero or more instances of this attribute MAY be present in
       packet.
 0-1   Zero or one instance of this attribute MAY be present in
       packet.
 1     Exactly one instance of this attribute MUST be present in
       packet.

DeKok Informational [Page 18] RFC 5997 Status-Server Practices August 2010

6. Examples

 A few examples are presented to illustrate the flow of packets to
 both the authentication and accounting ports.  These examples are not
 intended to be exhaustive; many others are possible.  Hexadecimal
 dumps of the example packets are given in network byte order, using
 the shared secret "xyzzy5461".

6.1. Minimal Query to Authentication Port

 The NAS sends a Status-Server UDP packet with minimal content to a
 RADIUS server on port 1812.
 The Request Authenticator is a 16-octet random number generated by
 the NAS.  Message-Authenticator is included in order to authenticate
 that the request came from a known client.
    0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02
    18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43
    82 20 97 c8 4f a3
     1 Code = Status-Server (12)
     1 ID = 218
     2 Length = 38
    16 Request Authenticator
    Attributes:
    18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
 The Response Authenticator is a 16-octet MD5 checksum of the Code
 (2), ID (218), Length (20), the Request Authenticator from above, and
 the shared secret.
    02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8
    b5 41 1d 66
    1 Code = Access-Accept (2)
    1 ID = 218
    2 Length = 20
   16 Request Authenticator
   Attributes:
      None.

DeKok Informational [Page 19] RFC 5997 Status-Server Practices August 2010

6.2. Minimal Query to Accounting Port

 The NAS sends a Status-Server UDP packet with minimal content to a
 RADIUS server on port 1813.
 The Request Authenticator is a 16-octet random number generated by
 the NAS.  Message-Authenticator is included in order to authenticate
 that the request came from a known client.
    0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7
    ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f
    da de 26 36 78 58
     1 Code = Status-Server (12)
     1 ID = 179
     2 Length = 38
    16 Request Authenticator
    Attributes:
    18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
 The Response Authenticator is a 16-octet MD5 checksum of the Code
 (5), ID (179), Length (20), the Request Authenticator from above, and
 the shared secret.
    02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a
    48 60 66 9c
     1 Code = Accounting-Response (5)
     1 ID = 179
     2 Length = 20
    16 Request Authenticator
    Attributes:
       None.

DeKok Informational [Page 20] RFC 5997 Status-Server Practices August 2010

6.3. Verbose Query and Response

 The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS
 server on port 1812.
 The Request Authenticator is a 16-octet random number generated by
 the NAS.
    0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13
    f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec
    61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
     1 Code = Status-Server (12)
     1 ID = 71
     2 Length = 44
    16 Request Authenticator
    Attributes:
     6  NAS-IP-Address (4) = 192.0.2.16
    18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
 The Response Authenticator is a 16-octet MD5 checksum of the Code
 (2), ID (71), Length (52), the Request Authenticator from above, the
 attributes in this reply, and the shared secret.
 The Reply-Message is "RADIUS Server up 2 days, 18:40"
    02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd
    6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72
    76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31
    38 3a 34 30
     1 Code = Access-Accept (2)
     1 ID = 71
     2 Length = 52
    16 Request Authenticator
    Attributes:
    32 Reply-Message (18)

7. Security Considerations

 This document defines the Status-Server packet as being similar in
 treatment to the Access-Request packet, and is therefore subject to
 the same security considerations as described in [RFC2865],
 Section 8.  Status-Server packets also use the Message-Authenticator
 attribute, and are therefore subject to the same security
 considerations as [RFC3579], Section 4.

DeKok Informational [Page 21] RFC 5997 Status-Server Practices August 2010

 We reiterate that Status-Server packets MUST contain a Message-
 Authenticator attribute.  Early implementations supporting Status-
 Server did not enforce this requirement, and were vulnerable to the
 following attacks:
  • Servers not checking the Message-Authenticator attribute could

respond to Status-Server packets from an attacker, potentially

       enabling a reflected DoS attack onto a real client.
  • Servers not checking the Message-Authenticator attribute could

be subject to a race condition, where an attacker could see an

       Access-Request packet from a valid client and synthesize a
       Status-Server packet containing the same Request Authenticator.
       If the attacker won the race against the valid client, the
       server could respond with an Access-Accept and potentially
       authorize unwanted service.
 The last attack is similar to a related attack when Access-Request
 packets contain a CHAP-Password but no Message-Authenticator.  We
 re-iterate the suggestion of [RFC5080], Section 2.2.2, which proposes
 that all clients send a Message-Authenticator in every Access-Request
 packet, and that all servers have a configuration setting to require
 (or not) that a Message-Authenticator attribute be used in every
 Access-Request packet.
 Failure to include a Message-Authenticator attribute in a Status-
 Server packet means that any RADIUS client or server may be
 vulnerable to the attacks outlined above.  For this reason,
 implementations of this specification that fail to require use of the
 Message-Authenticator attribute are NOT RECOMMENDED.
 Where this document differs from [RFC2865] is that it defines a new
 request/response method in RADIUS: the Status-Server request.  As
 this use is based on previously described and implemented standards,
 we know of no additional security considerations that arise from the
 use of Status-Server as defined herein.
 Attacks on cryptographic hashes are well known [RFC4270] and getting
 better with time.  RADIUS uses the MD5 hash [RFC1321] for packet
 authentication and attribute obfuscation.  There are ongoing efforts
 in the IETF to analyze and address these issues for the RADIUS
 protocol.

DeKok Informational [Page 22] RFC 5997 Status-Server Practices August 2010

8. References

8.1. Normative References

 [RFC1321]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
             April 1992.
 [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 [RFC2865]   Rigney, C., Willens, S., Rubens, A., and W. Simpson,
             "Remote Authentication Dial In User Service (RADIUS)",
             RFC 2865, June 2000.
 [RFC3539]   Aboba, B. and J. Wood, "Authentication, Authorization and
             Accounting (AAA) Transport Profile", RFC 3539, June 2003.
 [RFC4086]   Eastlake 3rd, D., Schiller, J., and S. Crocker,
             "Randomness Requirements for Security", BCP 106,
             RFC 4086, June 2005.
 [RFC4282]   Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The
             Network Access Identifier", RFC 4282, December 2005.
 [RFC5080]   Nelson, D. and A. DeKok, "Common Remote Authentication
             Dial In User Service (RADIUS) Implementation Issues and
             Suggested Fixes", RFC 5080, December 2007.

8.2. Informative References

 [RFC2866]   Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
 [RFC3579]   Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
             Dial In User Service) Support For Extensible
             Authentication Protocol (EAP)", RFC 3579, September 2003.
 [RFC4270]   Hoffman, P. and B. Schneier, "Attacks on Cryptographic
             Hashes in Internet Protocols", RFC 4270, November 2005.
 [RFC4668]   Nelson, D., "RADIUS Authentication Client MIB for IPv6",
             RFC 4668, August 2006.
 [RFC4669]   Nelson, D., "RADIUS Authentication Server MIB for IPv6",
             RFC 4669, August 2006.
 [RFC4670]   Nelson, D., "RADIUS Accounting Client MIB for IPv6",
             RFC 4670, August 2006.

DeKok Informational [Page 23] RFC 5997 Status-Server Practices August 2010

 [RFC4671]   Nelson, D., "RADIUS Accounting Server MIB for IPv6",
             RFC 4671, August 2006.

Acknowledgments

 Parts of the text in Section 3 defining the Request and Response
 Authenticators were taken, with minor edits, from [RFC2865],
 Section 3.
 The author would like to thank Mike McCauley of Open Systems
 Consultants for making a Radiator server available for
 interoperability testing.
 Ignacio Goyret provided valuable feedback on the history and security
 of the Status-Server packet.

Author's Address

 Alan DeKok
 The FreeRADIUS Server Project
 http://freeradius.org
 EMail: aland@freeradius.org

DeKok Informational [Page 24]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5997.txt · Last modified: 2010/08/30 23:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki