Internet DRAFT - draft-ietf-radext-status-realm

draft-ietf-radext-status-realm







radextra BOF                                                   M. Cullen
Internet-Draft                                         Painless Security
Intended status: Standards Track                                A. DeKok
Expires: 5 September 2024                                     FreeRADIUS
                                                             M. Donnelly
                                                       Painless Security
                                                              J. Howlett
                                                     Federated Solutions
                                                            4 March 2024


  Status-Realm and Loop Prevention for the Remote Dial-In User Service
                                (RADIUS)
                   draft-ietf-radext-status-realm-00

Abstract

   This document describes extension to the Remote Authentication Dial-
   In User Service (RADIUS) protocol to allow participants in a multi-
   hop RADIUS proxy fabric to check the status of a remote RADIUS
   authentication realm, gain visibility into the path that a RADIUS
   request will take across the RADIUS proxy fabric, and mitigate or
   prevent RADIUS proxy loops.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 5 September 2024.

Copyright Notice

   Copyright (c) 2024 IETF Trust and the persons identified as the
   document authors.  All rights reserved.






Cullen, et al.          Expires 5 September 2024                [Page 1]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://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 Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Requirements Notation . . . . . . . . . . . . . . . . . . . .   3
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Status-Realm Overview . . . . . . . . . . . . . . . . . .   6
     4.2.  RADIUS Loop Prevention Overview . . . . . . . . . . . . .   7
   5.  Packet Formats  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  Status-Realm-Request Packet . . . . . . . . . . . . . . .   7
     5.2.  Status-Realm-Response Packet  . . . . . . . . . . . . . .   8
   6.  Max-Hop-Count Attribute . . . . . . . . . . . . . . . . . . .   9
   7.  Status-Realm-Response-Code Attribute  . . . . . . . . . . . .   9
   8.  Server-Information Attribute  . . . . . . . . . . . . . . . .  11
     8.1.  Status-Realm Responding-Server  . . . . . . . . . . . . .  12
   9.  Status-Realm Implementation Requirements  . . . . . . . . . .  13
     9.1.  RADIUS Client Requirements  . . . . . . . . . . . . . . .  13
     9.2.  Server Requirements . . . . . . . . . . . . . . . . . . .  14
     9.3.  Proxy Server Requirements . . . . . . . . . . . . . . . .  15
   10. Status-Realm Implementation Status  . . . . . . . . . . . . .  16
     10.1.  Status-Realm Message Exchange Examples . . . . . . . . .  16
   11. Proxy Loop Detection Implementation Requirements  . . . . . .  17
     11.1.  Server Requirements  . . . . . . . . . . . . . . . . . .  17
     11.2.  Proxy Requirements . . . . . . . . . . . . . . . . . . .  17
   12. Proxy Loop Detection Implementation Status  . . . . . . . . .  17
     12.1.  Loop Detection Message Exchange Examples . . . . . . . .  17
   13. Management Information Base (MIB) Considerations  . . . . . .  18
   14. Interaction with RADIUS Client MIB Modules  . . . . . . . . .  18
   15. Table of Attributes . . . . . . . . . . . . . . . . . . . . .  19
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  19
   17. Security Considerations . . . . . . . . . . . . . . . . . . .  20
   18. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  21
   19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     19.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     19.2.  Informative References . . . . . . . . . . . . . . . . .  21
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22






Cullen, et al.          Expires 5 September 2024                [Page 2]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


1.  Introduction

   This document describes an extension to the Remote Authentication
   Dial-In User Service (RADIUS) protocol [RFC2865], to allow
   participants in a multi-hop RADIUS proxy fabric to check the status
   of a remote RADIUS authentication realm, gain visibility into the
   path that a RADIUS request will take across the RADIUS proxy fabric,
   and mitigate or prevent RADIUS proxy forwarding loops.

   This document defines two new RADIUS Packet Type Codes:

   *  Status-Realm-Request (TBD)

   *  Status-Realm-Response (TBD)

   This document also defines the following RADIUS Attributes:

   *  Status-Realm-Response-Code (TBD)

   *  Max-Hop-Count (TBD)

   *  Server-Identifier (TBD)

2.  Requirements Notation

   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].

3.  Terminology

   The following terms are used throughout this document.  Their
   definitions are included here for consistency and clarity.

   RADIUS Request           A RADIUS Request is the first message in a
                            RADIUS message exchange.  RADIUS request
                            message types include: Access-Request,
                            Accounting-Request, and Status-Server.  This
                            document defines a new RADIUS Request
                            message type: Status-Realm-Request.

   RADIUS Response          A RADIUS Response is any RADIUS message sent
                            in reply to a RADIUS Request.  RADIUS
                            reponse message types include: Access-
                            Accept, Access-Challenge, Access-Reject,
                            Accounting-Response.  This document defines
                            a new RADIUS Response message type: Status-
                            Realm-Response.



Cullen, et al.          Expires 5 September 2024                [Page 3]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   RADIUS Instance          A single device or software module that
                            implements the RADIUS protocol.

   RADIUS Client            A RADIUS Client is a RADIUS Instance that
                            sends RADIUS Request messages and recevies
                            RADIUS Reponse messages in reply.

   RADIUS Server            A RADIUS Server is a RADIUS Instance that
                            receives RADIUS Requests and sends RADIUS
                            Response messages in reply.

   Authentication Request   An Authentication Request is sent to
                            authenticate a particular user within a
                            particular realm.  The user and realm
                            information are typically included in a
                            User-Name Attribute [RFC2865] within the
                            Authentication Request.

   Authentication Server    An Authentication Server is a RADIUS Server
                            that receives Access-Requests for a given
                            RADIUS Realm, and sends Access-Access,
                            Access-Challenge or Access-Reject messages
                            in response.  A single Authentication Server
                            may serve more than one Authentication
                            Realm.

   Authentication Realm     An Authentication Realm consists of a group
                            of users within a single organization that
                            can be authenticated using RADIUS.  A single
                            Authentication Realm MAY be served by more
                            than one Authentication Server.

   Target Realm             The Target Realm of a RADIUS Request is the
                            RADIUS Realm toward which the Request is
                            directed.  The Target Realm is typically
                            contained within the "User-Name" attribute
                            of a Request.

   RADIUS Proxy             A RADIUS Proxy receives RADIUS Requests and
                            forwards then towards the Target Realm
                            included in the RADIUS Request message.  It
                            also receives the corresponding RADIUS
                            Respone message and fowards them back
                            towards the RADIUS Client that originated
                            the request.  In this context forwarding a
                            RADIUS Requst consists of generating a new
                            RADIUS Request containing information from
                            the original Request, and sending it to the



Cullen, et al.          Expires 5 September 2024                [Page 4]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


                            configured next-hop RADIUS server for the
                            Target Realm.  Forwarding a RADIUS Response
                            consists of sending it to the RADIUS Server
                            from which the corresponding Request was
                            received.

   RADIUS Proxy Fabric      A multi-hop group of inter-connected RADIUS
                            Servers that Proxy requests among themselves
                            towards a set of Target Realms.

   RADIUS Proxy Path        The RADIUS Server Path is a the set of
                            RADIUS Servers that a RADIUS Request
                            traverses from the first RADIUS Server that
                            is contacted by the RADIUS Client to the
                            final RADIUS Server that responds to the
                            Request.

   Proxy Loop               A Proxy Loop may occur when two or more
                            RADIUS Proxies are configured such that a
                            RADIUS Request follow a circular path
                            through the Proxy Fabric, never reaching the
                            Target Realm.  This is a pathological and
                            potentially damaging misconfiguration.

   First-Hop Server         The First-Hop Server is the first RADIUS
                            Server within a Proxy Fabric to recieve a
                            RADIUS Request.  In some cases, the First-
                            Hop RADIUS Server may receive the request
                            from a separate RADIUS Client.  In other
                            case, the First-Hop RADIUS Server and the
                            RADIUS Client may be running in a single
                            RADIUS Instance.

   Last-Hop Proxy           The Last-Hop Proxy is the last RADIUS Proxy
                            to forward a RADIUS Request before it
                            reaches the Authentication Server.
                            Depending on its configuraiton, the Last-Hop
                            Proxy may or may not know that is the Last-
                            Hop Proxy for a given RADIUS Request.

   Note: It is possible for a single RADIUS instance to server in
   multiple roles.  For example, it is common for a RADIUS Server to act
   as an Authentication Server for some Realms, while acting as a Proxy
   for other Realms.  A RADIUS Proxy will, by its nature, act as a
   RADIUS Server for some RADIUS messages while acting as a RADIUS
   Client for others.  The requirements in this document apply to all
   RADIUS instances whenever they are acting in the role to which the
   requirement applies.



Cullen, et al.          Expires 5 September 2024                [Page 5]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


4.  Overview

   This document defines two functional extensions to RADIUS: Querying
   the status of a remote RADIUS Realm (Status-Realm), and mitigating,
   detecting and preventing loops in a RADIUS Proxy forwarding loops
   (Proxy Loop Prevention).  This section contains a short overview of
   each function.  Detailed definitions and requirements are covered in
   later sections of this document.

4.1.  Status-Realm Overview

   Status-Realm-Request messages are sent by RADIUS Clients to to query
   the reachability and status of a particular Target Realm.  In some
   cases, the Status-Realm RADIUS Client may be able to reach an
   Authentication Server for the Target Realm directly.  In other cases,
   the RADIUS Client will send the initial Status-Realm request to a
   RADIUS Proxy, which will forward the Status-Realm-Request toward the
   indicated realm.

   Status-Realm-Requests may be sent to the RADIUS authentication port
   or the RADIUS accounting port of the first-hop RADIUS server.  RADIUS
   proxies should forward Status-Realm-Requests received on the
   authentication port to the authentication port of the next-hop RADIUS
   server.  Status-Realm-Requests received on the accounting port
   should, similarly, be forwarded to the accounting port of the next-
   hop server.

   When a Status-Realm-Request packet is received by an Authentication
   Server for the Target Realm, the Authentication Server MUST respond
   with a Status-Realm-Response packet.

   If an intermediate RADIUS Proxy is unable to forward a Status-Realm-
   Request packet towards the Target Realm, either because it has no
   information about how to reach the Target Realm, or because there are
   no reachable Authentication Servers for the Target Realm, the RADIUS
   Proxy MUST return a Status-Realm-Response packet containing a Status-
   Realm-Response-Code attribute.

   Status-Realm packets allow the sender to determine the reachability
   and status of a Authentication Realm, without requiring a direct
   RADIUS connection to a RADIUS Server for the Target realm, and
   without requiring credentials for an authorized user within that
   realm.  This can be useful for debugging RADIUS authentication
   issues, identifying routing issues within a RADIUS proxy fabric, or
   monitoring realm availability.






Cullen, et al.          Expires 5 September 2024                [Page 6]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   Using the Max-Hop-Count attribute defined in this document, RADIUS
   Clients can also implement "traceroute-like" functionality,
   discovering a series of proxies on route to a target realm.

4.2.  RADIUS Loop Prevention Overview

   RADIUS Proxies are configured to know which next-hop RADIUS Server to
   use for a given Target Realm.  There is no dynamic routing protocol
   or tree-spanning protocol in use, so Proxy Loops are a common
   occurence due to misconfiguration.  These loops can be controlled or
   prevented using implementation-specific or operator-specific
   mechanisms, but it would be useful to have well-defined, common
   mechanism.

   The Max-Hop-Count attribute described in this document can be used to
   mitigate the damage caused by Proxy Loops.  The Max-Hop-Count
   attribute is set to a small integer by the RADIUS Client or First-Hop
   RADIUS Server.  The value is decremented each time a RADIUS message
   is proxied.  When the Max-Hop-Count reaches zero, the request is
   discarded, ending the loop.

   This document also defines a more effective method of detecting and
   preventing Proxy Forwarding Loops: RADIUS Loop Prevention.  This
   document defines a RADIUS Server-Identifier attribute that is used to
   uniquely identify a RADIUS Server.  When a RADIUS Proxy receives a
   RADIUS Request packet, it checks to see if the Request contains a
   Server-Identifier attribute indicating that it has already processed
   this packet.  If so, it discards the packet.  If not, it adds its own
   Server Identifier to the packet before forwarding it.

5.  Packet Formats

   This section describes the RADIUS packet formats for Status-Realm-
   Request and Status-Realm-Response packets.  Status-Realm-Requests are
   sent in the same format, whether they are sent to the authentication
   port or the accounting port.

5.1.  Status-Realm-Request Packet

   Status-Realm-Request packets reuse the RADIUS packet format, with the
   fields and values for those fields as defined in [RFC2865],
   Section 3.









Cullen, et al.          Expires 5 September 2024                [Page 7]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   A Status-Realm-Request packet MUST include a Message-Authenticator
   attribute, as defined in [RFC2869], section 5.14.  The Message-
   Authenticator provides per-packet authentication and integrity
   protection.  The Authenticator field of a Status-Realm-Request packet
   MUST be generated using the same method as that used for the Request
   Authenticator field of Access-Request packets.

   A Status-Realm-Request packets MUST include a User-Name Attribute,
   containing the Target Realm for the Request.  The 'user' portion of
   the User-Name SHOULD be ignored, if present.

   A Status-Realm-Request message MUST also include a Max-Hop-Count
   attribute, as defined above.

   Status-Realm-Requests MAY include NAS-Identifier, and one of (NAS-IP-
   Address or NAS-IPv6-Address).  These attributes are not necessary for
   the operation of Status-Realm, but may be useful information to a
   server that receives those packets.

   Status-Realm-Request packets MUST NOT contain authentication
   credentials (such as User-Password, CHAP-Password, EAP-Message) or
   User or NAS accounting attributes (such as Acct-Session-Id, Acct-
   Status-Type, Acct-Input-Octets).

5.2.  Status-Realm-Response Packet

   Status-Realm-Response packets reuse the RADIUS packet format, with
   the fields and values for those fields as defined in [RFC2865],
   Section 3.

   The Response Authenticator field of a Status-Realm-Response packet
   MUST be generated using the same method used for calculating the
   Response Authenticator of an Access-Accept or an Access-Reject sent
   in response to an Access-Request, with the Status-Realm-Request
   Request Authenticator taking the place of the Access-Request Request
   Authenticator.

   The Status-Realm-Response packet MUST contain a Status-Realm-
   Response-Code attribute, as defined below, indicating the results of
   the Status-Realm request.

   The Status-Realm-Response packet MAY contain the following
   attributes: Reply-Message, Message-Authenticator, Server-Information.

   Note that when a server responds to a Status-Realm-Request packet, it
   MUST NOT send more than one Status-Realm-Response packet.





Cullen, et al.          Expires 5 September 2024                [Page 8]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


6.  Max-Hop-Count Attribute

   This section defines a new RADIUS attribute, Max-Hop-Count (TBD).
   The value of the Max-Hop-Count attribute is an integer, as defined in
   [RFC8044], Section 3.1.  Valid values are small positive integers, 0
   to 255.

   This attribute is used to limit the number of RADIUS servers that
   will proxy a packet before it reaches its final destination.  When a
   RADIUS server that implements the Max-Hop-Count Attribute determines
   that it wants to proxy a RADIUS Request to another RADIUS Server, it
   will check the Max-Hop-Count attribute.  If the Max-Hop-Count
   attribute is present and the value is zero, the Request MUST NOT be
   forwarded and an error response SHOULD be returned, as appropriate to
   the request type.  If the Max-Hop-Count is greater than zero, the
   proxy server MUST decrement the hop count by 1 before forwarding the
   request.

   In the context of Status-Realm-Requests, this attribute can be used
   to implement "traceroute-like" functionality.  By sending a series of
   Status-Realm-Requests with incremented values of Max-Hop-Count,
   starting with a Max-Hop-Count value of O, the RADIUS Client will
   receive a series of Status-Realm-Responses from the RADIUS Proxies on
   the Proxy Path to a given Target Realm.

   When used on other types of RADIUS Request messages, this option can
   mitigate the damage caused by RADIUS proxy loops.  It is therefore
   possible that a RADIUS Client or a RADIUS proxy server will support
   the Max-Hop-Count attribute, even if they do not support Status-
   Realm.  When used to limit RADIUS proxy loops, it is RECOMMENDED that
   the value of the Max-Hop-Count attribute be set to 32, by default.

   For any type of RADIUS request message, setting the Max-Hop-Count
   attribute to 0 effectively requests that the request message not be
   proxied.  Setting the attribute to a value greater than 0 requests
   that the request message be proxied across at most that many
   intermediate proxies between the visited and home server.

   If this attribute is not present on a RADIUS Request received from a
   RADIUS Client, the First-Hop RADIUS Server MAY add this option,
   setting it to the default value of 32, or to any valid, configured
   value.

7.  Status-Realm-Response-Code Attribute

   This section defines a new RADIUS attribute, Status-Realm-Response-
   Code (TBD).  This is of type tlv, as defined in [RFC8044], section
   3.13.  It contains 3 sub-attributes:



Cullen, et al.          Expires 5 September 2024                [Page 9]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   *  Response-Code (Type = 1)

   *  Hop-Count (Type = 2)

   *  Responding-Server (Type = 3)

   Response-Code is of type 'integer', as defined in [RFC8044],
   Section 3.1.  Exactly one Response-Code sub-attribute MUST be
   included in in every Status-Realm-Response-Code attribute.  It will
   contain one of the following values:

      0        The target realm is available

      1        No proxy route to the target realm
      2        No available servers for the target realm
      3        The target realm is missing or invalid
      4        Max-Hop-Count exceeded

      5-255    Unspecified error, the target realm is unreachable

      256      Administratively prohibited, target realm status
               unknown

      257      Internal error, target realm status unknown

      258      Bad Status-Realm-Request, missing or invalid
               Target Realm in the request message, target
               realm status unknown

      259      Bad Status-Realm-Request, missing or invalid
               Max-Hop-Count, target realm status unknown

      260-511  Unspecified error, Target Realm status unknown

      512+     Reserved

   Response-Code values from 0 to 255 indicate the status of the target
   realm on the RADIUS network.  Response-Code values from 256 to 511
   indicate errors in processing the Status-Realm request, and cannot
   indicate the status of the target realm.

   Hop-Count is of type 'integer'.  Valid values are 0-255.  The value
   of this sub-attribute MUST be set to the value of the Max-Hop-Count
   attribute in the received Status-Realm-Request.  If no Max-Hop-Count
   is included in the Status-Realm-Request message, this sub-attribute
   MUST be omitted.





Cullen, et al.          Expires 5 September 2024               [Page 10]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   Responding-Server is of type 'tlv', as defined in [RFC8044],
   Section 3.13.  This sub-attribute MUST be returned in every Status-
   Realm-Response attribute.  The value field of this sub-attribute
   contains a Server-Information Attribute for the responding server, as
   described below.

8.  Server-Information Attribute

   The Server-Information attribute is used to identify a specific
   RADIUS Server.  It MAY be added to any RADIUS Request message to
   indicate that a particular RADIUS Server has processed the Request.
   If present in a RADIUS Request, it SHOULD be copied into the
   corresponding RADIUS Response.  RADIUS Servers SHOULD NOT add Server-
   Information attributes to Response messages when processing
   Responses.

   This attribute is of type 'tlv', as defined in [RFC8044],
   Section 3.13.  The value of this attribute consists of a set of sub-
   attributes, all of type 'tlv'.  Each sub-attribute contains an
   identifier for a RADIUS proxy.  The Server-Identifier MUST have at
   least one sub-attribute and MAY have more than one sub-attribute.  If
   multiple sub-attributes are present, a RADIUS proxy MUST match all of
   the sub-attributes in order to match the identifier.

   The following sub-attributes may be included in the value field of a
   Server-Information Attribute.  The Type code for each sub-attribute
   is included in parenthesis.

   *  Server-Operator (Type = 1)

   *  Server-Identifier (Type = 2)

   *  Hop-Count (Type = 3)

   *  Time-Delta (Type = 4)

   The Server-Operator is of type 'string'.  It is the analogue of the
   Operator-Name, as defined in [RFC5580].

   The Server-Identifier in an analogue of the NAS-Identifier defined in
   [RFC2865].  It indicates the name of this particular proxy server.
   This field is used to identify which server processed the Request,
   among those operated by the organization indicated in the Server-
   Operator sub-attribute.

   The Time-Delta attribute is of type 'integer'.  It represents the
   number of milliseconds the request took to return through this proxy
   server.  For the target server, this value SHOULD be 0.



Cullen, et al.          Expires 5 September 2024               [Page 11]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


8.1.  Status-Realm Responding-Server

   This attribute is also included as the sub-attribute Responding-
   Server within the Status-Realm-Response-Code attribute, defined
   above, to indicate which RADIUS Server has sent the Status-Realm-
   Response message.  Thus, a Status-Realm response may contain many
   Server-Information attributes, as well as a Status-Realm-Response-
   Code attribute with the Responding-Server sub-attribute, which has
   the same structure.

   If a Status-Realm request targeting "target-realm" is routed over
   proxy servers P1 and P2 before reaching the "target-realm" home
   server, then the response message will contain these attributes:

   *  Server-Information:

      -  Server-Operator: P1

      -  Server-Identifier: P1

      -  Hop-Count: 32

      -  Time-Delta: 90

   *  Server-Information:

      -  Server-Operator: P2

      -  Server-Identifier: P2-Alpha

      -  Hop-Count: 31

      -  Time-Delta: 60

   *  Status-Realm-Response-Code:

      -  Response-Code: 0 (Available)

      -  Hop-Count: 30

      -  Responding-Server:

         o  Server-Operator: target-realm

         o  Server-Identifier: radius1.target-realm

         o  Hop-Count: 30




Cullen, et al.          Expires 5 September 2024               [Page 12]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


         o  Time-Delta: 0

9.  Status-Realm Implementation Requirements

   This section describes implementation details and requirements for
   RADIUS Clients and servers that support Status-Realm.

9.1.  RADIUS Client Requirements

   When Status-Realm-Request packets are sent from a RADIUS 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-Realm-Request packet should be generated
   and sent, with new Identity and Authenticator fields.

   RADIUS Clients MUST include the Message-Authenticator attribute in
   all Status-Realm-Request packets.  Failure to do so would mean that
   the packets could be trivially spoofed, leading to potential denial-
   of-service (DoS) attacks.

   The RADIUS Client MUST include a User-Name attribute in the request.
   The "user" portion of the username SHOULD be omitted.  The "realm"
   portion of the username is the target realm for the Status-Realm
   request.

   RADIUS Clients that support Status-Realm-Requests SHOULD allow a user
   or administrator to set or configure the Count value of the Max-Hop-
   Count Attribute described above.  If a different value is not
   indicated, the RADIUS Client SHOULD include a Max-Hop-Count attribute
   with a Count value of 32 in the Status-Realm-Request packet to
   prevent the possibility that Status-Realm-Requests will loop
   indefinitely.

   The RADIUS Client MAY increment packet counters as a result of
   sending a Status-Realm-Resquest or receiving a Status-Realm-Response.
   The RADIUS 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.

   RADIUS Clients MAY send Status-Realm-Request packets to the RADIUS
   destination ports from the same source port(s) used to send other
   Request packets.  Other RADIUS Clients MAY choose to send Status-
   Realm-Request packets from a unique source port that is not used to
   send other Request packets.

   In the case where a RADIUS Client sends a Status-Realm-Request
   packets from a source port also used to send other Request packets,
   the Identifier field MUST be unique across all outstanding Request



Cullen, et al.          Expires 5 September 2024               [Page 13]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   packets for that source port, independent of the value of the RADIUS
   Code field for those outstanding requests.  Once the RADIUS Client
   has either received a corresponding Status-Realm-Response packet or
   determined that the Status-Realm-Request has timed out, it may reuse
   the Identifier in another Request packet.

   The RADIUS Client MUST validate the Response Authenticator in the
   Status-Realm-Response.  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.

9.2.  Server Requirements

   Servers SHOULD permit administrators to globally enable or disable
   the acceptance of Status-Realm-Request packets.  The default SHOULD
   be that acceptance is enabled.  Servers SHOULD also permit
   administrators to enable or disable acceptance of Status-Realm-
   Request packets on a per-RADIUS Client basis.  The default SHOULD be
   that acceptance is enabled.

   If a server does not support Status-Realm, or if it is configured not
   to respond to Status-Realm-Requests, then it MUST silently discard
   any Status-Realm-Requests messages that it receives.  If a server
   receives a Status-Realm-Request packet from a RADIUS Client from
   which it is configured not to accept Status-Realm-Requests, then it
   MUST silently discard the message.

   If a server supports Status-Realm, is configured to respond to
   Status-Realm-Requets, and receives a Status-Realm-Request packet from
   a permitted RADIUS Client, it MUST first validate the Message-
   Authenticator attribute as defined in [RFC3579], Section 3.2.
   Packets failing this validation MUST be silently discarded.

   If the Status-Realm-Request passes Message-Authenticator validation,
   then the server should check if the Target Realm matches a local
   realm served by this Server.  If it does match, the server should
   send a Status-Realm-Response packet indicating that status of the
   Target Realm, reachable or unreachable (Status-Server-Response-Code =
   0 or 2).

   If the Target Realm does not match a local realm, then the server
   should determine whether it is configured to proxy packets towards
   the Target Realm.  If so, the server should implement the Proxy
   Server Requirements, below.  Servers SHOULD ignore the value of the
   "user" portion of the User-Name attribute, if any.






Cullen, et al.          Expires 5 September 2024               [Page 14]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   Servers SHOULD NOT discard Status-Realm packets merely because they
   have recently sent the RADIUS 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 decide to send an error response to a Status-Realm-
   Request packet based on local-site policy.  For example, a server
   that is running but is unable to perform its normal duties SHOULD
   send a Status-Realm-Response packet indicating an internal error
   (Status-Server-Response-Code = 257).  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 current
   load.

   The server MAY increment packet counters or create log entries as a
   result of receiving a Status-Realm-Request packet or sending a
   Status-Realm-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.

   If the Status-Realm-Request packet includes a Max-Hop-Count
   attribute, that attribute (with its current value) MUST be returned
   in any corresponding Status-Realm-Response packet.

   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 the standards-track specification [RFC2865], as it
   defines a new Message Type Code for packets to port 1812.  This
   specification is not compatible with the informational document
   [RFC2866], as it adds a new Code (Status-Realm-Request) that is valid
   for port 1813.

9.3.  Proxy Server Requirements

   Many RADIUS servers act as RADIUS proxies, forwarding requests to
   other RADIUS servers.  Such servers SHOULD proxy Status-Realm-Request
   packets to enable RADIUS Clients to determine the status of
   Authentication Realms that are not directly connected to the RADIUS
   Client.

   RADIUS proxies that support Status-Realm-Requests MUST support the
   Max-Hop-Count attribute defined above.  Before forwarding a Status-
   Realm-Request packet, a proxy MUST check the Max-Hop-Count Attribute.
   If the Max-Hop-Count attribute is present and the Count is zero (0),



Cullen, et al.          Expires 5 September 2024               [Page 15]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   the proxy MUST send a Status-Realm-Response indicating that the hop
   count has been exceeded (Status-Server-Response-Code = 4), and MUST
   NOT forward the packet.  If the Max-Hop-Count attribute is present,
   and the Count value is not zero, the proxy MUST decrement the Max-
   Hop-Count value before forwarding the packet.

   The RADIUS proxy MUST check the "realm" portion of the User-Name
   attribute in the Status-Realm-Request to determine the Target Realm
   for the request.  If the target realm is missing or malformed, the
   RADIUS proxy MUST send a Status-Realm-Response indicating an invalid
   realm (Status-Server-Response-Code = 3).  If the realm is properly
   formed, the Status-Realm-Request packet should be proxied toward the
   Target Realm, using the same next-hop RADIUS server that the proxy
   server would use for other request packets received on the same port.

   In some cases, a RADIUS proxy may not have an available next-hop
   RADIUS server for the Target Realm.  In that case, the RADIUS proxy
   server MUST send a Status-Realm-Response packet indicating that there
   is no proxy route to the Target Realm (Status-Server-Response-Code =
   1).

   In cases where a RADIUS proxy is configured to have a direct
   connection to the RADIUS server(s) of the Target Realm, but is
   configured not to forward Status-Realm-Request packets to the target
   server(s), the proxy MAY use other methods to determine the status of
   the Target Realm (such as Status-Server packets or recent Access-
   Request state information), and send a Status-Realm-Response
   indicating the determined state of the Target Realm (Status-Server-
   Response-Code = 0 or 2).  If the proxy is configured not to forward
   Status-Realm-Request packet to the Target Realm and does not have
   other methods to detect the status of the Target Realm, it SHOULD
   return a Status-Realm-Response packet indicating that the request is
   administrative prohibited (Status-Server-Response-Code = 257).

   If the Status-Realm-Request packet includes a Max-Hop-Count
   attribute, that attribute (with its current value) MUST be returned
   in any corresponding Status-Realm-Response packet.

10.  Status-Realm Implementation Status

   There is an initial implementation of Status-Realm available here:

   https://github.com/alandekok/freeradius-server/tree/Status-Realm

10.1.  Status-Realm Message Exchange Examples

   Message exchange examples are TBD.




Cullen, et al.          Expires 5 September 2024               [Page 16]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


11.  Proxy Loop Detection Implementation Requirements

   This section describes implementation details and requirements for
   RADIUS Clients, Servers and Proxies that support Proxy Loop
   Detection.

11.1.  Server Requirements

   A RADIUS Server that implements Proxy Loop Prevention add its own
   Server-Information Attribute to any RADIUS message that it generates,
   including RADIUS Response messages.  It MUST also copy all Server-
   Information atributes from a received RADIUS Request into any RADIUS
   Response that it generates in reply to that Request.

11.2.  Proxy Requirements

   A RADIUS Proxy that implements the Loop Prevention mechanism defined
   in this document MUST be configured with information to populate a
   Server-Information attribute, and matching criteria to determine if a
   Server-Information attribute in an incoming request indicates the
   existence of a Proxy Loop.

   Before forwarding a RADIUS Request towards the Target Realm, a RADIUS
   Proxy that implements Proxy Loop Prevention MUST examine each of the
   Server-Information attributes included in the Request message to
   determine whether the message is caught in a Proxy Loop.  If so, the
   Proxy should discard the message.  If a Proxy Loop is not detected,
   the RADIUS Proxy MUST add its own Server-Information attribute to any
   RADIUS Request that they forward toward the Target Realm.

12.  Proxy Loop Detection Implementation Status

   The Proxy Loop Detection mechanism is similar to RADIUS Vendor-
   Specific attribute used today to detect RADIUS Proxy Loops.  Unlike
   the Vendor-Specific attributes in use today, this mechanism includes
   server information within a single, globally-defrined attribute,
   rather than requiring that a unique vendor identifiers be allocated
   for each RADIUS Server operator.

12.1.  Loop Detection Message Exchange Examples

   Message exchange examples are TBD.









Cullen, et al.          Expires 5 September 2024               [Page 17]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


13.  Management Information Base (MIB) Considerations

   Status-Realm-Request packets are sent to the defined RADIUS ports, so
   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-Realm-Requests or
   implementations that are configured not to respond to Status-Realm-
   Request packets MUST use these counters to track received Status-
   Realm packets.

   If, however, Status-Realm-Requests are 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-Realm-
   Request or Status-Realm-Response packets.  That is, when a server
   fully implements Status-Realm, the counters defined in [RFC4669] and
   [RFC4671] MUST be unaffected by the transmission or reception of
   packets relating to Status-Realm-Requests.

   If a server supports Status-Realm-Request and the [RFC4669] or
   [RFC4671] MIB modules, then it SHOULD also support vendor-specific
   MIB extensions dedicated solely to tracking Status-Realm-Request and
   Status-Realm-Response packets.  Any definition of the server MIB
   modules for Status-Realm-Requests is outside of the scope of this
   document.

14.  Interaction with RADIUS Client MIB Modules

   RADIUS Clients implementing Status-Realm-Request MUST NOT increment
   [RFC4668] or [RFC4670] counters upon reception of Status-Realm-
   Response packets.  That is, when a RADIUS Client fully implements
   Status-Realm-Request, the counters defined in [RFC4668] and [RFC4670]
   MUST be unaffected by the transmission or reception of packets
   relating to Status-Realm.

   If an implementation supports Status-Realm-Request and the [RFC4668]
   or [RFC4670] MIB modules, then it SHOULD also support vendor-specific
   MIB extensions dedicated solely to tracking Status-Realm requests and
   responses.  Any definition of the RADIUS Client MIB modules for
   Status-Realm-Requests is outside of the scope of this document.









Cullen, et al.          Expires 5 September 2024               [Page 18]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


15.  Table of Attributes

   The following table provides a guide to which attributes may be found
   in Status-Realm-Request and Status-Realm-Response packets, and in
   what quantity.  Attributes other than the ones listed below SHOULD
   NOT be found in a Status-Realm-Request packet.

      Status-      Status-
      Realm-       Realm-
      Request      Response

      1            1              1      User-Name
      0            0              2      User-Password
      0            0              3      CHAP-Password
      0-1          0              4      NAS-IP-Address (Note 1)
      0            0+            18      Reply-Message
      0+           0+            26      Vendor-Specific
      0-1          0             32      NAS-Identifier (Note 1)
      0            0             79      EAP-Message
      1            0-1           80      Message-Authenticator
      0-1          0             95      NAS-IPv6-Address (Note 1)
      0            1             (TBD)   Status-Realm-Response-Code
      1            0             (TBD)   Max-Hop-Count
      0+           0+            (TBD)   Server-Information
      0            0             103-121 Digest-*

   Note 1: Status-Realm-Request 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 table entries included
   above:

      0     This attribute MUST NOT be present in packet.
      0+    Zero or more instances of this attribute MAY be present in
            the packet.
      0-1   Zero or one instance of this attribute MAY be present in
            the packet.
      1     Exactly one instance of this attribute MUST be present in
            the packet.

16.  IANA Considerations

   This document defines the Status-Realm-Request (TBD) and the Status-
   Realm-Response (TBD) RADIUS Packet Type Codes, both of which should
   be assigned by IANA from the Unassigned block of RADIUS Packet Type
   Codes.




Cullen, et al.          Expires 5 September 2024               [Page 19]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   This document defines three new RADIUS attributes, Max-Hop-Count
   (TBD) and Status-Realm-Response-Code (TBD) and Server-Identifier
   (TBD), which should be assigned by IANA from an Unassigned block of
   RADIUS Attribute Types, such as the Unassigned block for Extended-
   Attribute-1.

   This document also defines two new Protocol Registries that need to
   be created: "Values for RADIUS Attribute (TBD), Status-Realm-
   Response-Code" and "Valies for RADIUS Attribute (TBD), Server-
   Identifier".  Initial values for these registries are defined above.

17.  Security Considerations

   Status-Realm-Request packets are similar to Access-Request packets,
   and are therefore subject to the same security considerations as
   described in [RFC2865], Section 8.  Status-Realm packets also use the
   Message-Authenticator attribute, and are therefore subject to the
   same security considerations as [RFC3579], Section 4.

   We reiterate that all Status-Realm-Request packets MUST contain a
   Message-Authenticator.  Servers not checking the Message-
   Authenticator attribute could respond to Status-Realm packets from an
   attacker, potentially enabling a reflected DoS attack onto a real
   RADIUS Client.

   Where this document differs from [RFC2865] is that it defines a new
   request/response method in RADIUS: the Status-Realm-Request and
   Status-Realm-Response.  The Status-Realm-Request is similar to the
   previously described and widely implemented Status-Server message
   [RFC5997], and no additional security considerations are known to
   relate to the implementation or use of Status-Server.  This option
   differs from Status-Server because it is forwarded through proxies,
   so it can be sent to a RADIUS Server that does not have a direct
   connection to the Status-Realm RADIUS Client.  However, Access-
   Request packets are also forwarded, and there should be no additional
   attacks other than those incurred by forwarding Status-Realm-Request
   packets.

   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.

   Security Considerations for Loop Prevention are TBD.






Cullen, et al.          Expires 5 September 2024               [Page 20]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


18.  Acknowledgements

   This document was written using xml2rfc, as described in [RFC7991]

   Some of the sections in this document were adapted from the
   description of the Status-Server RADIUS Packet Type Code in
   [RFC5997].

19.  References

19.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, DOI 10.17487/RFC2865, June 2000,
              <https://www.rfc-editor.org/info/rfc2865>.

   [RFC8044]  DeKok, A., "Data Types in RADIUS", RFC 8044,
              DOI 10.17487/RFC8044, January 2017,
              <https://www.rfc-editor.org/info/rfc8044>.

19.2.  Informative References

   [RFC1321]  Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
              DOI 10.17487/RFC1321, April 1992,
              <https://www.rfc-editor.org/info/rfc1321>.

   [RFC2866]  Rigney, C., "RADIUS Accounting", RFC 2866,
              DOI 10.17487/RFC2866, June 2000,
              <https://www.rfc-editor.org/info/rfc2866>.

   [RFC2869]  Rigney, C., Willats, W., and P. Calhoun, "RADIUS
              Extensions", RFC 2869, DOI 10.17487/RFC2869, June 2000,
              <https://www.rfc-editor.org/info/rfc2869>.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579,
              DOI 10.17487/RFC3579, September 2003,
              <https://www.rfc-editor.org/info/rfc3579>.






Cullen, et al.          Expires 5 September 2024               [Page 21]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   [RFC4270]  Hoffman, P. and B. Schneier, "Attacks on Cryptographic
              Hashes in Internet Protocols", RFC 4270,
              DOI 10.17487/RFC4270, November 2005,
              <https://www.rfc-editor.org/info/rfc4270>.

   [RFC4668]  Nelson, D., "RADIUS Authentication Client MIB for IPv6",
              RFC 4668, DOI 10.17487/RFC4668, August 2006,
              <https://www.rfc-editor.org/info/rfc4668>.

   [RFC4669]  Nelson, D., "RADIUS Authentication Server MIB for IPv6",
              RFC 4669, DOI 10.17487/RFC4669, August 2006,
              <https://www.rfc-editor.org/info/rfc4669>.

   [RFC4670]  Nelson, D., "RADIUS Accounting Client MIB for IPv6",
              RFC 4670, DOI 10.17487/RFC4670, August 2006,
              <https://www.rfc-editor.org/info/rfc4670>.

   [RFC4671]  Nelson, D., "RADIUS Accounting Server MIB for IPv6",
              RFC 4671, DOI 10.17487/RFC4671, August 2006,
              <https://www.rfc-editor.org/info/rfc4671>.

   [RFC5580]  Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and
              B. Aboba, "Carrying Location Objects in RADIUS and
              Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009,
              <https://www.rfc-editor.org/info/rfc5580>.

   [RFC5997]  DeKok, A., "Use of Status-Server Packets in the Remote
              Authentication Dial In User Service (RADIUS) Protocol",
              RFC 5997, DOI 10.17487/RFC5997, August 2010,
              <https://www.rfc-editor.org/info/rfc5997>.

   [RFC7991]  Hoffman, P., "The "xml2rfc" Version 3 Vocabulary",
              RFC 7991, DOI 10.17487/RFC7991, December 2016,
              <https://www.rfc-editor.org/info/rfc7991>.

Authors' Addresses

   Margaret Cullen
   Painless Security
   Phone: +1 (781)405-7464
   Email: margaret@painless-security.com


   Alan DeKok
   FreeRADIUS
   Email: aland@freeradius.org





Cullen, et al.          Expires 5 September 2024               [Page 22]

Internet-Draft   RADIUS Status-Realm and Loop Detection       March 2024


   Mark Donnelly
   Painless Security
   Phone: +1 (857)928-5967
   Email: mark@painless-security.com


   Josh Howlett
   Federated Solutions
   Phone: +44 (0)7510 666 950
   Email: josh@federated-solutions.com









































Cullen, et al.          Expires 5 September 2024               [Page 23]