]> Painless Security

+1 (781)405-7464 margaret@painless-security.com

InkBridge Networks

alan.dekok@inkbridge.io

Painless Security

+1 (857)928-5967 mark@painless-security.com

Federated Solutions

+44 (0)7510 666 950 josh@federated-solutions.com

RADIUS EXTensions Internet-Draft 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. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the RADIUS EXTensions mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction This document describes an 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 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)

Requirements Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

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.

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

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.

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 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 RADIUS Server for the Target Realm, the RADIUS Server MUST respond with a Status-Realm-Response packet. If a 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 RADIUS 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 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.

Proxy Chains and Loops 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. RADIUS Clients can also use the Max-Hop-Count attribute to implement "traceroute-like" functionality. By setting the Max-Hop-Count value to a series of increasing values, it is possible to discover the proxies which route packets to a target realm. As there is no relationship between independent Status-Realm packets, the path (or partial path) discovered by one Status-Realm packet is likely to be differerent from the path discovered by a different Sgtatus-Realm packet. 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.

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.

Status-Realm-Request Packet Status-Realm-Request packets reuse the RADIUS packet format, with the fields and values for those fields as defined in , Section 3. A Status-Realm-Request packet MUST include a Message-Authenticator (, section 5.14) as the first attribute in the packet. 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. As a result, all of the security issues for Access-Request also apply to Status-Realm-Request. A Status-Realm-Request packets MUST include a User-Name attribute which 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 below. 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). When a RADIUS Server receives a Status-Realm-Request with authentication credentials, it MUST respond with a Status-Realm-Response, and that Status-Realm-Response MUST contain a Status-Realm-Response-Code Attribute with Response-Code 503, Invalid Contents, user credential included.

Status-Realm-Response Packet Status-Realm-Response packets reuse the RADIUS packet format, with the fields and values for those fields as defined in , 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 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. When a server responds to a Status-Realm-Request packet, it MUST NOT send more than one Status-Realm-Response packet.

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 , Section 3.1. Valid values are small positive integers, 0 to 255. This attribute is used to limit the number of RADIUS Proxy hops that a packet will pass through before either it times out, or it reaches its final destination. Before a RADIUS Proxy forwards a Status-Realm-Request packet, it MUST 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. A RADIUS server which will not proxy the Status-Realm-Request packet MUST ignore the value of the Max-Hop-Count attribute. 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 0, the RADIUS Client will receive a series of Status-Realm-Responses from the RADIUS Proxies on the Proxy Path to a given Target Realm. The Max-Hop-Count attribute can used with other types of RADIUS Request messages, in order to mitigate the damage caused by RADIUS proxy loops. It is therefore possible that a RADIUS Client or a RADIUS Proxy 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.

Status-Realm-Response-Code Attribute This section defines a new RADIUS attribute, Status-Realm-Response-Code (TBD). This has data type tlv, as defined in , section 3.13. It contains 3 sub-attributes:

• Response-Code (Type = 1)
• Hop-Count (Type = 2)
• Responding-Server (Type = 3)

Response-Code has data type 'integer', as defined in , Section 3.1. Exactly one Response-Code sub-attribute MUST be included in in every Status-Realm-Response-Code attribute. Response-Code values are grouped into one of several ranges:

Range	Meaning
200-299	Successful response
300-399	Status unknown
400-499	Realm unreachable
500-599	Server error

The Response-Code value will be one of:

Code	Meaning
200	The target realm is available
300	Administratively prohibited, target realm status unknown
400	No proxy route to the target realm
401	No available servers for the target realm
402	The target realm is missing or invalid
403	Max-Hop-Count exceeded
500	Internal error, target realm status unknown
501	Bad Status-Realm-Request, missing or invalid Target Realm in the request message, target realm status unknown
502	Bad Status-Realm-Request, missing or invalid Max-Hop-Count, target realm status unknown
503	Invalid Contents, user credential included

Code 200 MUST be returned when the target of the Status-Realm-Request is available. Code 300 SHOULD be returned when the RADIUS Proxy is configured not to forward a Status-Realm-Request packet to the Target Realm and the RADIUS Proxy does not have other methods to detect the status of the Target Realm. Code 400 MUST be returned when the RADIUS Proxy server does not have a route to the Target Realm. Code 401 SHOULD be returned when the RADISU Server has a direct connection to the Target Realm RADIUS Server, is configured not to forward Status-Realm-Request packets to the Target Realm RADIUS Server, and the RADIUS Server believes that the Target Realm RADIUS Server is currently unreachable. An example of a reason to believe that the Target Realm RADIUS Server is unreachable is that the Target Realm RADIUS Server has not responded to recent valid RADIUS requests. Code 402 MUST be returned when a Status-Realm-Request specifies a realm with a valid format and the RADIUS Server knows that realm does not exist. For example, consider a RADIUS server is configured to be authoritative for all realms ending in ".invalid" that receives a request for "example.invalid" but does not have an entry for "example.invalid." This server MUST return code 402. Code 403 MUST be returned if the Max-Hop-Count is equal to zero (0). Code 500 SHOULD be returned if the RADIUS Server encounters an error not detailed in this document. Code 501 SHOULD be returned if the Status-Realm-Request contains a Target Realm that is invalid. An example of an invalid Target Realm would be "invalid", which does not follow the rules for DNS hostnames. Code 502 SHOULD be returned when the Status-Realm-Request does not contain the Max-Hop-Count attribute. Code 503 MAY be returned when the Status-Realm-Request contains a User-Name attribute that includes a username. If the RADIUS Server instead forwards the Status-Realm-Request to another RADIUS Server, then it MUST strip the username part of the credential from the User-Name attribute, leaving the Target Realm. Hop-Count has data 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. Responding-Server has data type 'tlv', as defined in , 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.

Server-Information Attribute The Server-Information attribute is used to identify a specific RADIUS Server. A RADIUS Proxy MAY append its own Server-Informatin to any RADIUS Request message it proxies, to indicate that it has processed the Request. A RADIUS Server MAY include its own Server-Information in any RADIUS Response message that it sends, to indicate that it has processed the requyest. A RADIUS Proxy which receives a RADIUS Response message SHOULD include its own Server-Information in any RADIUS Response message that it sends. A RADIUS Proxy which receives a Response message containing Server-Information attributes SHOULD then append those to any Response message that it sends (i.e. after its own Server-Information). A RADIUS Proxiy MUST NOT modify any existing Server-Information attributes in Response messages which they receive. This attribute has data type 'tlv', as defined in , 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 are defined for the Server-Information attribute.

Name	Type
Server-Operator	1
Server-Identifier	2
Hop-Count	3
Time-Delta	4
Server-IP-Address	5
Server-IPv6-Address	6

The Server-Information attribute may include any of Server-Operator, Hop-Count, and Time-Delta. The Server-Information attribute may also include any one of Server-Identifier OR Server-IP-Address OR Server-IPv6-Address. The attribute SHOULD NOT include more than one of Server-Identifier, Server-IP-Address, and Server-IPv6-Address. The Server-Operator has data type 'string'. It is the analogue of the Operator-Name, as defined in . The Server-Identifier in an analogue of the NAS-Identifier defined in . 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 has data 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. The Server-IP-Address has data type 'ipv4addr' and represents the IPv4 address of this particular proxy server. Similarly, the Server-IPv6-Address has data type 'ipv6addr' and represents the IPv6 address of this particular proxy server. Given the prevalance of network translation, it will be common for a server to be unaware of its commonly used address; therefore, a RADIUS Server SHOULD allow its administrator to configure the values used for these attributes.

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: 200 (Available)
  • Hop-Count: 30
  • Responding-Server:
    • Server-Operator: target-realm
    • Server-Identifier: radius1.target-realm
    • Hop-Count: 30
    • Time-Delta: 0

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

RADIUS Client Requirements When Status-Realm-Request packets are sent from a RADIUS Client, they MUST NOT be retransmitted. Instead, the Identifier 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 Identifier 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-Name attribute MUST be formatted as a Network Access Identifier (NAI), as described in RFC 7542. The NAI SHOULD follow the second alternative form, '"@" utf8-realm'. The "utf8-realm" portion of the NAI is the target realm for the Status-Realm request, and MUST follow the rules for NAI realms set out in section 2. 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. 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 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.

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 , 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. 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 = 500). 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 , Section 3, defines a number of RADIUS Codes, but does not make statements about which Codes are valid for port 1812. In contrast, , Section 3, specifies that only RADIUS Accounting packets are to be sent to port 1813. This specification is compatible with the standards-track specification , as it defines a new Message Type Code for packets to port 1812. This specification is not compatible with the informational document , as it adds a new Code (Status-Realm-Request) that is valid for port 1813.

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), the proxy MUST send a Status-Realm-Response indicating that the hop count has been exceeded (Status-Server-Response-Code = 403), 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 = 402). 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 = 400). 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 = 200 or 401). 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 administratively prohibited (Status-Server-Response-Code = 300). 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.

Status-Realm Implementation Status There is an initial implementation of Status-Realm available here: https://github.com/alandekok/freeradius-server/tree/Status-Realm

Status-Realm Message Exchange Examples Message exchange examples are TBD.

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

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.

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.

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.

Loop Detection Message Exchange Examples Message exchange examples are TBD.

Management Information Base (MIB) Considerations Status-Realm-Request packets are sent to the defined RADIUS ports, so they can affect the and [RFC4671] RADIUS server MIB modules. 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 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 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 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.

Interaction with RADIUS Client MIB Modules RADIUS Clients implementing Status-Realm-Request MUST NOT increment or counters upon reception of Status-Realm-Response packets. That is, when a RADIUS Client fully implements Status-Realm-Request, the counters defined in and MUST be unaffected by the transmission or reception of packets relating to Status-Realm. If an implementation supports Status-Realm-Request and the or 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.

Status-Realm 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. 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:

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

Security Considerations Status-Realm-Request packets are similar to Access-Request packets, and are therefore subject to the same security considerations as described in , Section 8. Status-Realm packets also use the Message-Authenticator attribute, and are therefore subject to the same security considerations as , 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 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 , 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 and getting better with time. RADIUS uses the MD5 hash for packet authentication and attribute obfuscation. There are ongoing efforts in the IETF to analyze and address these issues for the RADIUS protocol. The Server-Information Attribute section describes a pair of sub-attributes to represent the IPv4 and IPv6 addresses of a particular RADIUS server. Vendors and operators should be aware that including this sub-attribute has the potential to divulge information about private networks, if the RADIUS server is accessible from outside the private network. In the case where a RADIUS server lies behind a network translation and the operator desires to include the server-IP-Address or Server-IPv6-Address sub-attribute, the operator SHOULD configure the RADIUS Server to use the publicly routed IP address of the translation as the value of the sub-attribute. Security Considerations for Loop Prevention are TBD.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a protocol for carrying authentication, authorization, and configuration information between a Network Access Server which desires to authenticate its links and a shared Authentication Server. [STANDARDS-TRACK] RADIUS specifications have used data types for two decades without defining them as managed entities. During this time, RADIUS implementations have named the data types and have used them in attribute definitions. This document updates the specifications to better follow established practice. We do this by naming the data types defined in RFC 6158, which have been used since at least the publication of RFC 2865. We provide an IANA registry for the data types and update the "RADIUS Attribute Types" registry to include a Data Type field for each attribute. Finally, we recommend that authors of RADIUS specifications use these types in preference to existing practice. This document updates RFCs 2865, 3162, 4072, 6158, 6572, and 7268. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes the MD5 message-digest algorithm. The algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. This memo provides information for the Internet community. It does not specify an Internet standard. This document describes a protocol for carrying accounting information between a Network Access Server and a shared Accounting Server. This memo provides information for the Internet community. This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 and RFC 2866. This memo provides information for the Internet community. This document defines Remote Authentication Dial In User Service (RADIUS) support for the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication mechanisms. In the proposed scheme, the Network Access Server (NAS) forwards EAP packets to and from the RADIUS server, encapsulated within EAP-Message attributes. This has the advantage of allowing the NAS to support any EAP authentication method, without the need for method- specific code, which resides on the RADIUS server. While EAP was originally developed for use with PPP, it is now also in use with IEEE 802. This memo provides information for the Internet community. Recent announcements of better-than-expected collision attacks in popular hash algorithms have caused some people to question whether common Internet protocols need to be changed, and if so, how. This document summarizes the use of hashes in many protocols, discusses how the collision attacks affect and do not affect the protocols, shows how to thwart known attacks on digital certificates, and discusses future directions for protocol designers. This memo provides information for the Internet community. This memo defines a set of extensions that instrument RADIUS authentication client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication clients. This memo obsoletes RFC 2618 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2618 are carried forward into this document. The memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK] This memo defines a set of extensions that instrument RADIUS authentication server functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS authentication servers. This memo obsoletes RFC 2619 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2619 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. [STANDARDS-TRACK] This memo defines a set of extensions that instrument RADIUS accounting client functions. These extensions represent a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. Using these extensions, IP-based management stations can manage RADIUS accounting clients. This memo obsoletes RFC 2620 by deprecating the MIB table containing IPv4-only address formats and defining a new table to add support for version-neutral IP address formats. The remaining MIB objects from RFC 2620 are carried forward into this document. This memo also adds UNITS and REFERENCE clauses to selected objects. This memo provides information for the Internet community. X.500 collective attributes allow common characteristics to be shared between collections of entries. This document summarizes the X.500 information model for collective attributes and describes use of collective attributes in LDAP (Lightweight Directory Access Protocol). This document provides schema definitions for collective attributes for use in LDAP. This document describes procedures for conveying access-network ownership and location information based on civic and geospatial location formats in Remote Authentication Dial-In User Service (RADIUS) and Diameter. The distribution of location information is a privacy-sensitive task. Dealing with mechanisms to preserve the user's privacy is important and is addressed in this document. [STANDARDS-TRACK] 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. This document is not an Internet Standards Track specification; it is published for informational purposes. This document defines the "xml2rfc" version 3 vocabulary: an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 7749.

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