]> InkBridge Networks

aland@inkbridgenetworks.com

Internet RADEXT Working Group Internet-Draft RADIUS crypto-agility was first mandated as future work by RFC 6421. The outcome of that work was the publication of RADIUS over TLS (RFC 6614) and RADIUS over DTLS (RFC 7360) as experimental documents. Those transport protocols have been in wide-spread use for many years in a wide range of networks. They have proven their utility as replacements for the previous UDP (RFC 2865) and TCP (RFC 6613) transports. With that knowledge, the continued use of insecure transports for RADIUS has serious and negative implications for privacy and security. The publication of the "BlastRADIUS" exploit has also shown that RADIUS security needs to be updated. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates many insecure practices in RADIUS, and mandates support for secure TLS-based transport layers. Related security issues with RADIUS are discussed, and recommendations are made for practices which increase both security and privacy. About This Document Status information for this document may be found at . Discussion of this document takes place on the RADEXT Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction With the publication of , the work on crypto-agility is nearing completion. The RADIUS protocol now has a secure transport which is standards-track. This specification therefore completes the work of by deprecating insecure uses of RADIUS, including RADIUS/UDP and RADIUS/TCP. This specification mandates new behavior for RADIUS to address those issues, most notably the recent BlastRADIUS vulnerability . In the interest of clarity, these mandates are given with minimal explanation. The reader is instead directeed to for a detailed review of of the security and privacy issues in RADIUS.

Review of RADIUS Security and Privacy The RADIUS protocol was first standardized in 1997, though its roots go back much earlier to 1993. The protocol uses MD5 to authenticate some packets types, and to obfuscate certain attributes such as User-Password. As originally designed, Access-Request packets were entirely unauthenticated, and could be trivially spoofed ( and ). The insecurity of MD5 was first noted in relation to RADIUS in 1996 on the IETF RADIUS working group mailing list , which also discussed using an HMAC construct to increase security. While it was common knowledge at the time, the earliest record of concerns about Access-Request packets spoofing was on the RADIUS working group mailing list in 1998. There was substantial further discussions about the lack of integrity checks on the list over the next few years. The outcome of that process was the definition of Message-Authenticator as an optional HMAC-based attribute in . The packet forgery issue was further discussed in 2004 in , and again in 2007 in . The state of MD5 security was again discussed in , which states in Section 2:

• MD5 is no longer acceptable where collision resistance is required such as digital signatures.

That statement led to RADIUS security being reviewed in , but no protocol changes were made at that time. The outcome of that review was the text in the remainder of , which created crypto-agility requirements for RADIUS. The work of was completed in . Another issue is that RADIUS sends most information (but not passwords) "in the clear", with obvious privacy implications. Publicly available data includes information such as names, MAC addresses, locations, etc., which allows individuals to be tracked with minimal effort. The reader is refered to , and specifically to for detailed discussion, and to for recommendations on threat mitigations. It is no longer acceptable for RADIUS to rely on MD5 for security. It is no longer acceptable to send device or location information in clear text across the wider Internet. This document therefore deprecates all insecure uses of RADIUS, and mandates the use of secure TLS-based transport layers.

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

• RADIUS

• The Remote Authentication Dial-In User Service protocol, as defined in , , and among others.

• RADIUS/UDP

• RADIUS over the User Datagram Protocol as define above.

• RADIUS/TCP

• RADIUS over the Transport Control Protocol

• RADIUS/TLS

• RADIUS over the Transport Layer Security protocol

• RADIUS/DTLS

• RADIUS over the Datagram Transport Layer Security protocol

• TLS

• the Transport Layer Security protocol. Generally when we refer to TLS in this document, we are referring to RADIUS/TLS and/or RADIUS/DTLS.

• NAS

• Network Access Server, which is a RADIUS client.

• MS-CHAP

• Microsoft Challenge-Handshake authentication, as defined for MS-CHAPv1 in , MS-CHAPv2 in , and EAP-MSCHAPv2

In order to continue the terminology of , this document describes the Request Authenticator, Response Authenticator, and Message-Authenticator as "signing" the packets. This terminology is not consistent with modern cryptographic terms, but using other terminology could be misleading to long-term RADIUS imlementers. The reader is assured that no modern cryptographic methods are used with RADIUS/UDP.

Deprecating Insecure Practices The solution to an insecure protocol which uses thirty year-old cryptography is to deprecate the use insecure cryptography, and to mandate modern cryptographic transport. This section deprecates insecure transports, mandates the use of secure transports, officially deprecates MS-CHAP nearly two decades after it was broken, and finally closes out the crypto-agility requirements for RADIUS.

RADIUS/UDP and RADIUS/TCP are Deprecated RADIUS/UDP and RADIUS/TCP MUST NOT be used outside of secure networks. A secure network is one which is believed to be safe from eavesdroppers, attackers, etc. For example, if IPsec is used between two systems, then those systems may use RADIUS/UDP or RADIUS/TCP over the IPsec connection. However, administrators should not assume that such uses are always secure. An attacker who breaks into a critical system could use that access to view RADIUS traffic, and thus be able to attack it. Similarly, a network misconfiguration could result in the RADIUS traffic being sent over an insecure network. Neither the RADIUS client nor the RADIUS server would be aware of any network misconfiguration (e.g. such as could happen with IPsec). Neither the RADIUS client nor the RADIUS server would be aware of any attacker snooping on RADIUS/UDP or RADIUS/TCP traffic. In contrast, when TLS is used, the RADIUS endpoints are aware of all security issues, and can enforce any necessary security policies. Any use of RADIUS/UDP and RADIUS/TCP is therefore NOT RECOMMENDED, even when the underlying network is believed to be secure.

Secure Transports are Mandated All systems which send RADIUS packets outside of secure networks MUST use either IPsec, RADIUS/TLS, or RADIUS/DTLS. For operational and security reasons, it is RECOMMENDED to use RADIUS/TLS or RADIUS/DTLS instead of IPsec. Unlike (D)TLS, use of IPsec means that applications are generally unaware of transport-layer security. Any problem with IPsec such as configuration issues, negotiation or re-keying problems are typically presented to the RADIUS servers as 100% packet loss. These issues may occur at any time, independent of any changes to a RADIUS application using that transport. Further, network misconfigurations which remove all security are completely transparent to the RADIUS application: packets can be sent over an insecure link, and the RADIUS server is unaware of the failure of the security layer. In contrast, (D)TLS gives the RADIUS application completely knowledge and control over transport-layer security. The failure cases around (D)TLS are therefore often clearer, easier to diagnose and faster to resolve than failures in IPsec. For example, a failed TLS connection may return a "connection refused" error to the application, or any one of many TLS errors indicating which exact part of the TLS conversion failed during negotiation.

Recommended Practices for TLS Due to the ability of attackers to record sessions for later decryption, it is RECOMMENDED that all cryptographic methods used to secure RADIUS conversations provide forward secrecy. While forward secrecy will not protect individual sessions from attack, it will prevent attack on one session from being leveraged to attack other, unrelated, sessions. It is RECOMMENEDED that AAA servers minimize the impact of a session being decrypted by using a total throughput or time based limit. After that limit has bene reached, the session keys can be replaced though a process of either re-keying the existing connection, or by opening a new connection. The old connection can then be deprioritized for new traffic, and then closed. Note that if the original connection if closed before all outstanding requests have received responses, or before a new connection is full open, it can cause packet loss.

MS-CHAP is Deprecated MS-CHAP (as defined for v1 in , v2 in , and EAP-MSCHAPv2 ) has major design flaws, as discussed in . MS-CHAP MUST NOT be used in any situation where it is not protected by a secure transport protocol. MS-CHAP MUST NOT be sent over RADIUS/UDP or RADIUS/TCP, unless that data is protected by a a secure transport layer such as IPSec. As packets can be proxied outside of a secure transport, MS-CHAP SHOULD NOT be sent over RADIUS/UDP or RADIUS/TCP. For authentication protocols such as EAP, MS-CHAP SHOULD NOT be used outside of a secure tunnel such as PEAP or TTLS. This recommendation includes EAP-MSCHAPv2 . Implementers and administrators MUST treat MS-CHAP as being equivalent in security to sending passwords in the clear, without any encryption or obfuscation. That is, the User-Password attribute with the obfuscation is substantially more secure than MS-CHAP. MS-CHAP offers little benefit over PAP, and has many drawbacks as discussed here, and in the next section. Existing RADIUS client implementations SHOULD deprecate the use of all authentication methods based on MS-CHAP. Clients SHOULD forbid new configurations from enabling MS-CHAP authentication. New RADIUS clients MUST NOT implement MS-CHAPv1, MS-CHAPv2, or EAP-MSCHAPv2.

New Crypto-Agility Requirements The crypto-agility requirements of are addressed in Appendix C, and in Section 10.1 of . For clarity, we repeat the text of here, with some minor modifications to update references, without changing the content. Section 4.2 of makes a number of recommendations about security properties of new RADIUS proposals. All of those recommendations are satisfied by using TLS or DTLS as the transport layer. Section 4.3 of makes a number of recommendations about backwards compatibility with RADIUS. Section 3 addresses these concerns in detail. Section 4.4 of recommends that change control be ceded to the IETF, and that interoperability is possible. Both requirements are satisfied. Section 4.5 of requires that the new security methods apply to all packet types. This requirement is satisfied by allowing TLS and DTLS to be used for all RADIUS traffic. In addition, Section 3, addresses concerns about documenting the transition from legacy RADIUS to crypto-agile RADIUS. Section 4.6 of requires automated key management. This requirement is satisfied by using TLS or DTLS key management. This specification finalizes the work began in . This document updates to state that any new RADIUS specification MUST NOT introduce new "ad hoc" cryptographic primitives to authenticate packets as was done with the Request / Response Authenticator, or to obfuscate attributes as was done with User-Password and Tunnel-Password. We allow legacy RADIUS-specific cryptographic methods existing as of the publication of this document to be used for historical compatibility. However, all new cryptographic work which is specific to the RADIUS protocol is forbidden. We recognize that RADIUS/UDP will still be in use for many years, and that new standards may require some modicum of privacy. As the BlastRADIUS attack shows ( and Section TBD), RADIUS/UDP security is inadequate for modern networks. The solution is not to fix RADIUS/UDP. The solution is to deprecate it entirely. All new security and privacy requirements in RADIUS MUST be provided by a secure transport layer such as TLS or IPsec. As noted above, simply using IPsec is not always enough, as the use (or not) of IPsec is unknown to the RADIUS application. The restriction forbidding new cryptographic work in RADIUS does not apply to the data being transported in RADIUS attributes. For example, a new authentication method could use new cryptographic methods, and would be permitted to be transported in RADIUS. This authentication method could be a new EAP method, or any other data which is opaque to the RADIUS transport. In those cases, RADIUS serves as a transport layer for the authentication method. The authentication data is treated as opaque data for the purposes of Access-Request, Access-Challenge, etc. packets. There would be no need for the RADIUS protocol to define any new cryptographic methods in order to transport this data. Similarly, new specifications MAY define new attributes which use the obfuscation methods for User-Password as defined in Section 5.2, or for Tunnel-Password as defined in Section 3.5. However, due to the issues noted in , the Tunnel-Password obfuscation method MUST NOT be used for packets other than Access-Request, Access-Challenge, and Access-Accept. If the attribute needs to be send in another type of packet, then the protocol design is likely wrong, and needs to be revisited. It is again a difficult choice to forbid certain uses of the Tunnel-Password obfuscation method, but we believe that doing so is preferable to allowing sensitive data to be obfuscated with less security than the original design intent.

Securing Access-Request Packets Despite the above mandates to use secure transports for RADIUS, the reality is that RADIUS/UDP is likely to remain in wide-spread use for many years. It is therefore important to update RADIUS/UDP and RADIUS/TCP in order to secure them from the BlastRADIUS attack (). There are a number of changes required to both clients and servers in order for all possible attack vectors to be closed. Implementing only some of these mitigations means that an attacker could bypass those partial mitigations, and therefore still perform the attack. This section outlines the mitigations which protect RADIUS/UDP and RADIUS/TCP systems from the BlastRADIUS attack. These mitigations MUST be applied to RADIUS/UDP and RADIUS/TCP, and MUST NOT be applied to RADIUS/TLS or RADIUS/DTLS. Unless otherwise noted, the discussion here applies only to Access-Request packets, and to responses to Access-Request (i.e. Access-Accept, Access-Reject, Access-Challenge, and Protocol-Error packets). All behavior involving other types of request and response packets MUST remain unchanged. The mitigation methods outlined here allow systems to both protect themselves from the attack, while not breaking existing networks. There is no global “flag day” required for these changes. Systems which implement these recommendations are fully compatible with legacy RADIUS implementations, and can help to protect those legacy implementations. However, when these mitigations are not fully implemented, systems may still be vulnerable to the attack. Note that when the RADIUS system does not do proxying, the attack can be mitigated simply by upgrading the RADIUS server, so that it sends Message-Authenticator as the first attribute in all responses to Access-Request packets. However, the goal of this specification is to fix all architectures supported by RADIUS systems, rather than a limited subset. We therefore mandate new behavior for all RADIUS clients and servers, while acknowledging that some organizations may choose to not deploy all of the new functionality. For overall network security and good practice, we still recommend that all RADIUS clients and servers be upgraded to use the new software which contains the mitigations, and also be configured with the highest level of security. Doing so will ensure that configuration mistakes on one system will not reintroduce the vulnerability.

New Configuration Flags Clients and servers MUST implement the new configuration flags defined below, when RADIUS/UDP or RADIUS/TCP is used. These flags MUST NOT be exposed in any administrative interface, or examined when RADIUS/DTLS or RADIUS/TLS is used. The behavior and meaning of these flags will be discussed in the following sections. Introducing these flags before discussing their meaning makes the subsequent discussion simpler and easier to understand. The goal of these flags is to secure the RADIUS protocol without preventing communication between clients and servers, even when only one party has been upgraded. These flags are designed to allow a gradual migration from both parties using legacy RADIUS, to fully upgraded and secured systems with all of the mitigations in place.

• Clients MUST have a per-server boolean configuration flag, which we call “require Message-Authenticator”. The default value for this flag MUST be “false” in order to maintain compatibility with legacy servers. Servers MUST have a per-client boolean configuration flag, which we call “require Message-Authenticator”. The default value for this flag MUST be “false” in order to maintain compatibility with legacy clients. Servers MUST have a per-client boolean configuration flag, which we call “limit Proxy-State”. The default value for this flag MUST be “false” in order to maintain compatibility with legacy clients.

It is RECOMMENDED that implementations support both a global setting, and per-client or per-server setting for the above flags. For example, an implementation could support a global setting which is over-ridden by a more specific per-client or per-server setting. The global setting could also be used if there was no more specific setting defined. The combination of global and more narrow configuration allows administrators to upgrade systems gradually, without requiring a "flag day" when everything changes on a global basis. The following sections explain how these flags are used, by following the flow of an Access-Request packet being sent from the client, to being received by the server, to the server sending a response, and finally to that response being received by the client.

Clients and Access-Request The following new behavior is mandated for RADIUS/UDP and RADIUS/TCP clients:

• Clients MUST add Message-Authenticator to all Access-Request packets.

This behavior MUST NOT be configurable. Disabling it would open the system up to attack, and would prevent the other mitigation methods from working. The root cause of the attack is that Access-Request packets lack integrity checks. Therefore, the most important fix is to add integrity checks to those packets. The Message-Authenticator SHOULD be the first attribute in all Access-Request packets. That is, it should be placed immediately after the packet header. Implementations MAY place the Message-Authenticator elsewhere in an Access-Request packet. From a cryptographic point of view, the location of Message-Authenticator does not matter for Access-Request packets, it just needs to exist somewhere in the packet. However, the location of Message-Authenticator does matter for responses to Access-Request (Access-Accept, etc.). It is better to have consistent and clear messaging for addressing this attack, instead of having different recommendations for different kinds of packets. However, many existing RADIUS clients do not currently send Message-Authenticator. It also may be difficult to upgrade some client equipment, as the relevant vendor may have gone out of business, or may have marked equipment as “end of life” and thus unsupported. It is therefore necessary for servers to work with such systems so as to not break existing RADIUS deployments, while at the same time protecting them as much as practically possible.

Servers and Access-Request The following new behavior is mandated for for RADIUS/UDP and RADIUS/TCP servers:

• When receiving an Access-Request, servers MUST consult the value of the "require Message-Authenticator" flag prior to accepting the packet for processing. This flag MUST NOT be consulted for other types of request packets. If the "require Message-Authenticator" flag is set to “false”, servers MUST follow legacy behavior for validating and enforcing the existence of Message-Authenticator in Access-Request packets. For example, enforcing the requirement that all packets containing EAP-Message also contain a Message-Authenticator attributes, but otherwise accepting and validating the Message-Authenticator attribute if it is present, while taking no action if the attribute is missing. If the "require Message-Authenticator" flag is set to "false", servers MUST also check the value of the "limit Proxy-State" flag and either accept or discard the packet, based on the checks discussed in , below. If the "require Message-Authenticator" flag is set to “true”, the server MUST examine the Access-Request packets for the existence of the Message-Authenticator attribute. Access-Request packets which do not contain Message-Authenticator MUST be silently discarded. This discard process MUST occur before the Message-Authenticator or Request Authenticator have been validated. For packets which are not discarded by the preceding check, the server MUST then validate the contents of the Message-Authenticator and then discard packets which fail this validation as per . Servers MUST NOT discard a packet based on the location of the Message-Authenticator attribute. We extend to state that RADIUS clients and servers MUST NOT discard packets based on the order or location of any attribute. If Message-Authenticator passes validation, then the packet is authentic and it has not been modified. The location of Message-Authenticator within the packet does not matter for authenticated packets.

The default value for the "require Message-Authenticator" flag is “false” because many clients do not send the Message-Authenticator attribute in all Access-Request packets. Defaulting to a value of "true" would mean that the server would be unable to accept packets from many legacy clients, and existing networks would break. We note that if this flag is “false”, the server can be vulnerable to the attack, even if the client has been updated to always send Message-Authenticator in all Access-Requests. An attacker could simply strip the Message-Authenticator from the Access-Request, and proceed with the attack as if client had not been updated. The server then does not see Message-Authenticator in the Access-Request, and accepts the modified packet for processing. When the "require Message-Authenticator" flag is set to "true", the server is protected from the BlastRADIUS attack on this client to server link. Any packet which has been modified by the attacker to remove Message-Authenticator will be discarded by the server. Any packet containing Message-Authenticator will be validated using the HMAC-MD5 construct, which is not vulnerable to this attack. The server may still, however, be vulnerable to the attack if it proxies packets to another server. That is, the system as a whole is secure only when all possible client to server links are secured. Unfortunately, there is no way for clients and servers to negotiate protocol-layer features in RADIUS/UDP or RADIUS/TCP. A server cannot know if invalid packets are being discarded due to an ongoing attack, or if they are being discarded due to a mismatched configuration between client and server. Servers SHOULD therefore log the fact that an Access-Request packet was discarded (with rate limits) in order to inform the administrator that either an attack is underway, or that there is a configuration mismatch between client and server.

Detecting Configuration Mismatches As a special case for debugging purposes, instead of discarding the packet, servers MAY instead send a Protocol-Error or Access-Reject response packet. This packet MUST contain a Message-Authenticator attribute as the first attribute in the packet, otherwise an attacker could turn this response into an Access-Accept. The response MUST also contain an Error-Cause attribute with value 510 (Missing Message-Authenticator). The server MUST not send this response by default, as it this could cause the server to respond to forged Access-Request packets. The purpose of this Protocol-Error packet is to allow administrators to signal misconfigurations between client and server. It is intended to only be used temporarily when new client to server connections are being configured, and MUST be disabled permanently once the connection is verified to work. This behavior SHOULD only be enabled when specifically configured by an administrator. It MUST also be rate-limited, as there is no need to signal this error on every packet received by the server. It SHOULD be automatically disabled when the server receives an Access-Request from a client which contains Message-Authenticator. Implementations MAY instead automate this process, by sending a few such responses when packets from a client are first seen, and then not sending responses thereafter. As RADIUS clients are upgraded over time, RADIUS server implementations SHOULD enable the “require Message-Authenticator” flag by default. The next question is how to protect systems when legacy clients do not send Message-Authenticator.

Updated Servers and Legacy Clients The following new behavior is mandated for RADIUS/UDP and RADIUS/DTLS servers:

• When receiving an Access-Request and where the "require Message-Authenticator" flag is set to "false", servers MUST then consult the value of the "limit Proxy-State" flag for the client. If the "limit Proxy-State" flag is set to "false", servers MUST follow legacy behavior for validating and enforcing the existence of Message-Authenticator in Access-Request packets. For example, enforcing the requirement that all packets containing EAP-Message also contain a Message-Authenticator attributes, but otherwise accepting and validating the Message-Authenticator attribute if it is present, while taking no action if the attribute is missing. This behavior is the same as mandated by the previous section. If the "limit Proxy-State" flag is set to "true", servers MUST require that all Access-Request packets which contain a Proxy-State attribute also contain a Message-Authenticator attribute. Access-Request packets which contain Proxy-State but no Message-Authenticator MUST be silently discarded. If the packet does contain a Message-Authenticator. servers MUST validate its contents, and discard packets which fail this validation ().

This flag is motivated by the realization that most NASes (i.e. not proxies) will never send Proxy-State in an Access-Request packet. If a server sees Proxy-State in a packet from a NAS, it is a strong signal that an attacker is attempting the BlastRADIUS attack. The BlastRADIUS attack depends on the construction and behavior of Proxy-State, and the attack is essentially impossible without using Proxy-State in an Access-Request. It is therefore safe to add a configuration flag which checks for Proxy-State, because well-behaving NASes will never send it. The only time the server will see a Proxy-State from a NAS is when the attack is taking place. The behavior of this flag is not to simply discard Access-Request packets which contain an "unexpected" Proxy-State. Instead, the behavior is to require such packets to be authenticated. If a packet is authenticated via the existence of Message-Authenticator with validated contents, then the existence (or not) of Proxy-State does not matter; the packet should be accepted and processed by the server. On the other hand, if the packet cannot be authenticated by validating its Message-Authenticator, then the existence of an unexpected Proxy-State is suspicious, and the packet should be discarded. As with the previous section, servers SHOULD log a message when packets are discarded due to this flag. Servers MAY also send an error response as discussed above, subject to the caveats and considerations described in the previous section for those responses.

Server Responses to Access-Request The following behavior is mandated for RADIUS/UDP and RADIUS/TCP servers, when sending responses to Access-Request packets:

• Servers MUST add Message-Authenticator as the first attribute in all responses to Access-Request packets. That is, all Access-Accept, Access-Reject, Access-Challenge, and Protocol-Error packets. The attribute MUST be the first one in the packet, immediately after the 20 octet packet header.

Adding Message-Authenticator as the first attribute means that for the purposes of MD5 known prefix attacks, the unknown suffix begins with the Message-Authenticator, and continues for the remainder of the packet. The attacker is therefore unable to leverage the attack using a known prefix, and the vulnerability is mitigated. As it is difficult to upgrade both clients and servers simultaneously, we also need a method to protect clients when the server has not been updated. That is, clients cannot depend on the Message-Authenticator existing in response packets. Clients need to take additional steps to protect themselves, independent of any server updates.

Clients Receiving Responses The following new behavior is mandated for RADIUS/UDP and RADIUS/TCP clients:

• When receiving any response to an Access-Request packet (Access-Accept, Access-Challenge, Access-Reject, or Protocol-Error), clients MUST consult the "require Message authenticator" flag prior to accepting the packet for processing. This flag MUST NOT be consulted for responses to other types of request packets. If the "require Message-Authenticator" flag is set to “false”, clients MUST follow legacy behavior for validating and enforcing the existence of Message-Authenticator in response packets. For example, enforcing the requirement that all packets containing EAP-Message also contain a Message-Authenticator attributes, but otherwise accepting and validating the Message-Authenticator attribute if it is present, while taking no action if the attribute is missing. If the "require Message-Authenticator" flag is set to “true”, the client MUST examine the response packets for the existence of the Message-Authenticator attribute. Response packets which do not contain Message-Authenticator MUST be silently discarded. This check MUST be done before the Response Authenticator or Message- Authenticator has been verified. No further processing of discarded packets should take place. The client MUST validate the contents of the Message-Authenticator and discard packets which fail this validation (). Clients MUST NOT discard a packet based on the location of the Message-Authenticator attribute. If Message-Authenticator passes validation, then the packet is authentic and it has not been modified. The location of Message-Authenticator within the packet does not matter for authenticated packets.

When the response is discarded, the client MUST behave as if no response was received. That is, any existing retransmission timers MUST NOT be modified as a result of receiving a packet which is silently discarded. Unfortunately, the client cannot determine if invalid packets are being discarded due to an ongoing attack, or if they are being discarded due to a mismatched configuration between client and server (e.g. mis-matched shared secret). The client SHOULD log the fact that the packet was discarded (with rate limits) in order to inform the administrator that either an attack is underway, or that there is a configuration mismatch between client and server. The above discussions have followed the complete path from client, to server, and back again. If each client to server hop is secured via the above methods, then by construction, systems using RADIUS/UDP or RADIUS/TCP are no longer vulnerable to the BlastRADIUS attack.

Status-Server While the BlastRADIUS attack works only for Access-Request packets, Access-Accept or Access-Reject can also be sent in response to Status-Server packets (). In order to simplify client implementations, we mandate the following new behavior with respect to Status-Server:

• Servers MUST follow the above recommendations relating to Message-Authenticator when sending Access-Accept, Access-Challenge, or Access-Reject packets, even if the original request was Status-Server.

This requirement ensures that clients can examine responses independent of any requests. That is, a client can perform a simple verification pass of response packets prior to doing any more complex correlation of responses to request. We note that states:

• .. all Status-Server packets MUST include a Message-Authenticator attribute. Failure to do so would mean that the packets could be trivially spoofed.

As a result, compliant implementations of do not need to change their behavior with respect to sending or receiving Status-Server packets: they are already protected against the BlastRADIUS attack.

Documentation and Logging It is RECOMMENDED that RADIUS server implementations document the behavior of these flags in detail, including how they help protect against this attack. An informed administrator is more likely to engage in secure practices. Similarly, when any of the above flags cause a packet to be discarded, the system SHOULD log a descriptive message (subject to rate limiting) about the problematic packet. This log is extremely valuable to administrators who wish to determine exactly what is going wrong, and what actions can be taken to correct the issue.

Summary The following list outlines the requirements on client implementations, and references the prior sections which contain the normative text. The intent is to give readers a short checklist which lets them quickly validate that their implementations are correct. While the following list does not contain normative text (in order to avoid potential conflict or confusion), the reader should follow the references below to verify that the behavior described below is truly normative.

• clients include Message-Authenticator in all Access-Request packets,
  • clients can place Message-Authenticator as the first attribute in all Access-Request packets, but this placement is not required for security.
• clients validate the contents of Message-Authenticator in all packets that they receive,
• clients do not check the location of Message-Authenticator in any response packet that they receive,
• clients do not discard packets which contain unknown attributes,
• clients implement a boolean configuration flag "require Message-Authenticator",
  • If set to "false", clients do not take any additional steps.
  • if set to "true", clients discard all responses to Access-Request packets which do not contain Message-Authenticator. This discard happens before the Response Authenticator or Message-Authenticator are validated.

The following list outlines requirements on server implementations, with the same explanations and caveats given above for the list of requirements on client implementations.

• servers validate the contents of Message-Authenticator in all packets that they receive,
• server do take check the location of Message-Authenticator in any request packet that they receive,
• servers do not discard packets which contain unknown attributes,
• servers implement a boolean configuration flag "require Message-Authenticator",
  • If set to "false", servers implement checks for the "limit Proxy-State" flag.
  • if set to "true", servers discard all Access-Request packets which do not contain a Message-Authenticator attribute. This discard happens before the Request Authenticator or Message-Authenticator are validated. Servers then do not implement the checks for the "limit Proxy-State" flag.
• servers implement a boolean configuration flag "limit Proxy-State", and .
  • servers check this flag only when the "require Message-Authenticator" flag is set to "false".
  • If set to "false", servers take no further action.
  • If set to "true", servers discard all Access-Request packets which do not contain Message-Authenticator, and which also contain one or more Proxy-State attributes. This discard happens before the Request Authenticator or Message-Authenticator are validated.
• servers include Message-Authenticator in all responses to Access-Request packets,
• servers include Message-Authenticator in all Access-Accept, Access-Reject, Access-Challenge, and Protocol-Error packets, and
• servers place Message-Authenticator as the first attribute in all responses to Access-Request packets, and in all Access-Accept, Access-Reject, and Access-Challenge packets, .

New Requirements on Clients and Servers This section defines a number of updates to the RADIUS protocol, in order to address interoperability issues. While these updates do not directly increase the security of the protocol, they correct implementation errors which cause the protocol to be more fragile.

Attribute Location and Ordering While states that attribute ordering does not matter, some implementations would discard packets attributes were not received in a particular order chosen by the implementer. Specifically, some implementations misunderstood the requirement (from the BlastRADIUS mitigations) that Message-Authenticator is sent as the first attribute in responses to Access-Request packets. Despite the mandate that clients do not check the location of Message-Authenticator, non-compliant implementations would discard valid and authentic Access-Request packets where Message-Authenticator was not the first attribute. This behavior is not appropriate. The text defining attribute order (quoted below) does not cover all possible cases: We add a missing case here. A RADIUS client or server MUST NOT have dependencies on the order or location of a particular attribute. A RADIUS client or server MUST NOT discard otherwise valid packets which have attributes in an order which is unexpected to the implementation, but which is valid by the above rules. For example, if Message-Authenticator passes validation, then the packet is authentic and it has not been modified. The location of Message-Authenticator within the packet does not matter for authenticated packets. If can be the first, second, or last attribute, without any difference in meaning.

Unknown Attributes Another outcome of the BlastRADIUS mitigations was the discovery that some implementations would discard packets which contained an attribute that they did not recognize. While this behavior is not explicitly permitted by previous specifications, it is not explicitly forbidden, either. This document corrects that failure. Unknown attributes are defined as attributes which are well-formed, but which are not recognized by the implementation. Processing of unknown attributes is discussed in :

• A RADIUS server MAY ignore Attributes with an unknown Type. A RADIUS client MAY ignore Attributes with an unknown Type.

We note this recommendation is to "ignore" these attributes, and not to discard the encapsulating packet. Instead of ignoring unknown attributes, some implementations erroneously discard those packets. This behavior leads to interoperability issues and network problems. We update to require that implementations MUST ignore Attributes with an unknown Type. Those attributes MUST be treated in the same manner as an "Invalid Attribute" which is defined in . The only exception to the above requirements is CoA-Request and Disconnect-Request packets, as discussed in . For all situations other than the ones discussed in , implementations MUST NOT discard a packet if it contains an attribute with an unknown Type. This behavior is secure, so long as implementations follow some additional guidance for Access-Accept packets. This guidance follows logically from existing text in for similar situations with Access-Challenge:

• If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead.

And also for Service-Type in :

• A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead.

A client is not required to implement all possible authorizations which can be sent in an Access-Accept. We therefore extend the above scenarios to packets which contain unknown Types. A client MUST treat Access-Accepts with no known or supported authorizations as though an Access-Reject had been received instead. This requirement for unknown Types is already met by most, if not all, RADIUS implementations. That is, experience has shown that discarding packets for arbitrary reasons causes problems. Existing implementations have largely chosen to follow reasonable practices, and the recommendation here simply documents that wide-spread practice.

Delaying Access-Rejects Anyone can cause a NAS to send Access-Request packets at will, simply by attempting to requesting network access, or login permissions from the NAS. If this login process is not rate-limited, it can be abused by an attacker to perform dictionary attacks. In order to prevent these brute-force attacks, servers which directly receive packets from a NAS MUST enforce a minimum delay between reception of the Access-Request and transmission of any corresponding Access-Reject. This delay SHOULD be configurable. Experience shows that values of about one (1) second work well in practice. Implementers should note that this delay requirement does not need to be implemented proxies or home servers. A proxy or home server MAY enforce a similar delay between reception of the Access-Request and transmission of a corresponding Access-Reject. For proxies, this delay MUST NOT be additive. That is, proxies do not add a fixed delay to Access-Reject packets. Instead, proxies can enforce a minimum delay between Access-Request and Access-Reject. If multiple servers in a chain of proxies were to each add a delay, the delays woud be cumultative, and therefore problematic. Therefore, the requirement is for proxies to enforce a minimum delay. Servers SHOULD also add a small random jitter to any preconfigured delay, in order to better protect themselves from timing attacks.

Migrating Away from Insecure Transports We recognize that it is difficult to upgrade legacy devices with new cryptographic protocols and user interfaces. The problem is made worse because of the volume of RADIUS devices which are in use. The exact number is unknown, and can only be approximated. Our best guess is that at the time of this writing there are millions of devices supporting RADIUS/UDP in daily use. It takes significant time and effort to correct the deficiencies of all of them. This section therefore documents a migration path from RADIUS/UDP to secure transports. In the following sections, we give a number of migration steps which could each be done independently. We recommend increased entropy for shared secrets. Finally, where Section 2.3 makes support for TLS-PSK optional, we suggest that RADIUS/TLS and RADIUS/DTLS implementations SHOULD support TLS-PSK.

Recommending TLS-PSK Given the insecurity of RADIUS/UDP, the absolute minimum acceptable security is to use strong shared secrets. However, administrator overhead for TLS-PSK is not substantially higher than for shared secrets, and TLS-PSK offers significantly increased security and privacy. It is therefore RECOMMENDED that implementations support TLS-PSK. In some cases TLS-PSK is preferable to certificates. It may be difficult for RADIUS clients to upgrade all of their interfaces to support the use of certificates, and TLS-PSK more closely mirrors the historical use of shared secrets, with similar operational considerations. Additional implementation and operational considerations for TLS-PSK are given in .

Network Operators It is RECOMMENDED that all RADIUS traffic be sent over a management VLAN. This recommendation should be followed even if TLS transport is used. There is no reason to mix user traffic and management traffic on the same network. Using a management network for RADIUS traffic will generally prevent anyone other than trusted administrators from attacking RADIUS. We say “generally”, because security is limited by the least secure part of the network. If a network device has some unrelated vulnerability, then an attacker could exploit that vulnerability to gain access to the management network. The attacker would then be free to exploit the RADIUS infrastructure. As noted above, it is RECOMMENED that all RADIUS traffic use TLS transport between client and server, even when the local network is believed to be secure. While IPSec is useful to connect disparate sites across untrusted networks, it is still useful to use TLS transport to secure RADIUS traffic. A defense in depth strategy helps to protect the network from both active attacks, and from accidental changes which decrease network security. All networking equipment should be physically secure. There is no reason to have critical portions of networking infrastructure physically accessibly to the public. Where networking equipment must be in public areas (e.g. access points), that equipment SHOULD NOT have any security role in the network. Instead, any network security validation or enforcement SHOULD be done by separate equipment which is in a physically secure location. Similarly, the use of RADIUS/TCP in any circumstances is NOT RECOMMENDED. Any system which supports RADIUS/TCP is also likely to support TLS, and that SHOULD be used instead.

Deploying the BlastRADIUS Mitigations The preceding sections define requirements for client and server implementations which address the BlastRADIUS attack. It is useful to also provide guidelines for administrators as to how, and when, to set the new configuration flags. The guidelines provided in this section are a suggestion only. Administrators are free to take other actions as they see fit. The guidelines provided here are known to provide minimal outages while upgrading complex systems. As such, it is RECOMMENDED that administrators follow the steps outlined here, in order, so that RADIUS systems can be upgraded with minimal impact to operational networks.

1. Administrators SHOULD upgrade servers before upgrading clients. There are many fewer clients than servers, and upgrading servers can often protect clients which are not upgraded.
2. Administrators SHOULD configure servers to set "limit Proxy-State" to "true" for all clients which are NASes. i.e. clients which are not proxies.
3. Administrators of servers which proxy packets SHOULD verify that all "next hop" proxies have been upgraded, and that they return Message-Authenticator in all responses to Access-Request packets.
4. Once step (3) has been validated, administrators SHOULD configure their proxy so that the outgoing client configuration sets the "require Message-Authenticator" flag to "true".
5. Administrators of servers which receive proxied packets (i.e. packets not from a NAS) SHOULD configure the server to set the the "require Message-Authenticator" flag to "true" for each client which is an upgraded proxy.

Once the above five steps are followed, the network should be secure, and any client upgrade and configuration can be done over time. For client upgrades, administrators can proceed with the following steps:

1. Administrators SHOULD upgrade clients individually, i.e. one at a time. Upgrading multiple clients at the same time is NOT RECOMMENDED.
2. Once a client has been upgraded, administrators SHOULD verify that it sends Message-Authenticator in all Access-Request packets.
3. Once step (2) has been validated, administrators SHOULD configure each server that receives packets from that client to set the "require Message-Authenticator" flag to "true" for that client.
4. If a server has been updated, administrators SHOULD verify that it sends Message-Authenticator as the first attribute in all responses to Access-Request packets.
5. Once step (4) has been validated, administrators SHOULD configure each client receiving packets from that server to set the "require Message-Authenticator" flag to "true" for that server.

Once all of the above steps are followed for all clients and servers, the network is secure from the BlastRADIUS attack.

Practices to Increase RADIUS Security and Privacy While we still permit the use of UDP and TCP transports in secure environments, there are opportunities for increasing the security of RADIUS when those transport protocols are used. The amount of personal identifiable information (PII) sent in packets should be minimized. Information about the size, structure, and nature of the visited network should be omitted or anonymized. The choice of authentication method also has security and privacy impacts. The recommendations here for increasing the security of RADIUS transports also applies when TLS is used. TLS transports protect the RADIUS packets from observation by from third-parties. However, TLS does not hide the content of RADIUS packets from intermediate proxies, such as ones uses in a roaming environment. As such, the best approach to minimizing the information sent to proxies is to minimize the number of proxies which see the RADIUS traffic, and to minimize the amount of PII which is sent. Implementers and administrators need to be aware of all of these issues, and then make the best choice for their local network which balances their requirements on privacy, security, and cost. Any security approach based on a simple "checklist" of "good / bad" practices is likely to result in decreased security as compared to an end-to-end approach which is based on understanding the issues involved.

Use Long and Complex Shared Secrets Section 3 says:

• It is preferred that the secret be at least 16 octets. This is to ensure a sufficiently large range for the secret to provide protection against exhaustive search attacks. The secret MUST NOT be empty (length 0) since this would allow packets to be trivially forged.

This recommendation is no longer adequate, so we strengthen it here. RADIUS implementations MUST support shared secrets of at least 32 octets, and SHOULD support shared secrets of 64 octets. Implementations MUST warn administrators that the shared secret is insecure if it is 12 octets or less in length. Administrators SHOULD use shared secrets of at least 24 octets, generated using a source of secure random numbers. Any other practice is likely to lead to compromise of the shared secret, user information, and possibly of the entire network. Creating secure shared secrets is not difficult. The following figure outlines four separate ways to create shared secrets. Only one of the above commands should be run, as they are functionally equivalent. Each command reads 128 bits (16 octets) of random data from a secure source, and encodes it as printable / readable ASCII. This form of PSK will be accepted by any implementation which supports at least 32 octets for PSKs. Larger PSKs can be generated by changing the "16" number in the command to a larger value. The above derivation assumes that the random source returns one bit of entropy for every bit of randomness which is returned. Sources failing that assumption are NOT RECOMMENDED. Given the simplicity of creating strong secrets, there is no excuse for using weak shared secrets with RADIUS. The management overhead of dealing with complex secrets is less than the management overhead of dealing with compromised networks. Over all, the security analysis of shared secrets is similar to that for TLS-PSK. It is therefore RECOMMENDED that implementers manage shared secrets with same the practices which are recommended for TLS-PSK, as defined in Section E.7 and Section 4. On a practical note, implementers SHOULD provide tools for administrators to help them create and manage secure shared secrets. The cost to do so is minimal for an implementer. Providing such tools can further enable and motivate administrators to use secure practices.

Use Constant Time Comparisons Both clients and servers SHOULD use constant-time operations to compare received versus calculated values which depend on secret information. If comparison operations are stopped as soon as a difference is seen, an attacker could using timing attacks to determine the correct underlying values, even without seeing them. A constant-time operation instead compares the entire value, accumulating the result along the way. Only when the entire value has been examined does the comparison return a "match" or "no-match" result. Constant-time operations SHOULD be used for the Request Authenticator and Response Authenticator fields. Constant time comparisons SHOULD be used for attributes which directly contain secret values (e.g. User-Password), or are derived from secret values (e.g. CHAP-Password, and Message-Authenticator).

Limit the use of User-Password The design of RADIUS means that when proxies receive Access-Request packets, the clear-text contents of the User-Password attribute are visible to the proxy. Despite various claims to the contrary, the User-Password attribute is never sent "in the clear" over the network. Instead, the password is protected by TLS (RADIUS/TLS) or via the obfuscation methods defined in . However, the nature of RADIUS means that each proxy must first undo the password obfuscation of , and then re-do it when sending the outbound packet. As such, the proxy has the clear-text password visible to it, and stored in its application memory. It is therefore possible for every intermediate proxy to snoop and record all User-Name and User-Password values which they see. This exposure is most problematic when the proxies are administered by an organization other than the one which operates the home server. Even when all of the proxies are operated by the same organization, the temporary existence of clear-text passwords on multiple machines is a security risk. It is therefore NOT RECOMMENDED for organizations to send the User-Password attribute in packets which are sent outside of the organization. If RADIUS proxying is necessary, another authentication method which provides for end-to-end security of user information SHOULD be used, such as EAP-TLS, TTLS, or PEAP. Organizations MAY still use User-Password attributes within their own systems. Client and server implementations MUST use secure programming techniques to wipe passwords and other sensitive data from memory when they are no longer needed.

Use PAP in preference to CHAP and MS-CHAP When the system as a whole is taken into account, the risk of password compromise is substantially less with PAP than with CHAP or MS-CHAP. The full reasons are outlined in an . It is therefore RECOMMENDED that administrators use PAP in preference to CHAP or MS-CHAP. It is also RECOMMENDED that administrators store passwords "at rest" in a secure form (salted, hashed), as with the "crypt" format discussed above. That being said, other authentication methods such as EAP-TLS and EAP-pwd do not expose clear-text passwords to the RADIUS server or any intermediate proxy. Thor methods therefore lower the risk of password exposure even more than using PAP. It is RECOMMENDED that administrators avoid password-based authentication methods where at all possible.

Use EAP Where Possible If more complex authentication methods are needed, there are a number of EAP methods which can be used. These methods variously allow for the use of certificates (EAP-TLS), or passwords (EAP-TTLS , PEAP )) and EAP-pwd . We also note that the TLS-based EAP methods which transport passwords also hide the passwords from intermediate RADIUS proxies, which also increases security. Finally, password-based EAP methods still send PAP / CHAP / MS-CHAP inside of the TLS tunnel. As such, the security of a home server which checks those passwords is subject to the analysis above about PAP versus CHAP, along with the issues of storing passwords in a database.

Minimize the use of Proxies The design of RADIUS means that even when RADIUS/TLS is used, every intermediate proxy has access to all of the information in each packet. The only way to secure the network from such observers is to minimize the use of proxies. Where it is still necessary to use intermediate proxies such as with eduroam and OpenRoaming , it is RECOMMENDED to use EAP methods instead of bare PAP, CHAP, or MS-CHAP. If passwords are used, they can be can be protected from being seen by proxies via TLS-based EAP methods such as EAP-TTLS or PEAP. Passwords can also be omitted entirely from being sent over the network, as with EAP-TLS or EAP-pwd . In many cases, however, the existence of proxies is to either due contractual obligations, or to a need to solve "N by M" connection problems. A centralized proxy system can often simplify overall network management and maintenance.

Eliminate Proxies Where Possible The best way to avoid malicious proxies is to eliminate proxies entirely. The use of dynamic peer discovery () means that the number of intermediate proxies is minimized. However, the server on the visited network still acts as a proxy between the NAS and the home network. As a result, all of the above analysis still applies when peer discovery is used. There is an intermediate system which may have access to passwords or PII. The only solution is using end-to-end security for AAA, which would involve a completely new protocol.

There is no RADIUS Routing Protocol While allows for a client to connect directly to a server, that configuration is not always used. Historically, RADIUS systems implemented realm roaming, where multiple visited networks were connected to multiple home via chains of intermediate proxies . As there is no RADIUS routing protocol to control realm forwarding through these proxies, there is therefore no way to automatically determine which realms are routable, or how best to route packets for known realms. The outcome of this limitation is that all such realm routing rules are largely configured statically, manually, and individually on multiple systems. This process can be automated within one administrative system, but it is open to mistakes or abuse in multi-system networks. In RADIUS, each proxy which sees traffic is completely trusted. It can modify, filter, or record any packets which transit the proxy. This ability means that a proxy can engage in a large number of negative behaviors. For example, a proxy could forge Access-Request packets for realms which it knows about, and potentially perform dictionary attacks on home networks. A proxy could also alter or invent data in Accounting-Request packets, in order to defraud a home server of revenue. A proxy could also observe Accounting-Request traffic, and use the obtained information to forge Disconnect-Request packets. Proxies can also inject traffic for realms which do not normally transit the proxy. Without a routing protocol, there is no way for a home server to automatically control which set of realms is allowed to be sent from a particular client. There is also no general way for a proxy to signal that a particular Access-Request or Accounting-Request is non-routable: it must be either rejected or discarded. Visited sites also have no control over proxies past the ones that they have relationships with. Subsequent proxies are completely unknown, and unknowable to the visited network. Despite these systems being completely unknown, they are completely trusted due to limitations in the RADIUS protocol. That is, there is no fine-grained way for a visited or home network to limit which intermediary systems see traffic for their realms, or what traffic can be seen by those systems. While these filtering rules can be manually documented as seen in , this process is error-prone, and fragile. Administrators should be aware of the above issues: fraud, forgery, and filtering are all possible in a "trusted" RADIUS ecosystem. Historically, these issues do not appear to have been widely exploited. The most common defense against these attacks is to limit RADIUS relationships to entities which share a contractual relationship. This relationship can be direct between clients, servers, and proxies. This relationship can also be indirect, as when multiple organizations are members of a shared consortium such as eduroam. Implementations therefore SHOULD provide methods by which routing information can be tied to particular clients and to particular home servers. Implementations SHOULD allow packets to be filtered by some combination of realm and client or home server. Administrators SHOULD take advantage of these filters to double-check that received traffic is coming from the expected sources, and contains the expected realms.

Dynamic Discovery and Filtering When dynamic discovery is used, intermediate proxy hops are avoided. There are a number of possible attacks here, though largely limits its discussion to rate limiting of connections. A client which supports dynamic discovery of home servers still has to perform filtering on NAI realms before doing any lookups. When no filtering takes place, an attacker can cause a RADIUS client to do DNS lookups for arbitrary domains, and then cause it to connect to arbitrary servers. As there is no RADIUS routing protocol, there is no general way for a client to determine which realms are part of a particular organization, and are thus permitted for dynamic DNS lookups. Organizations relying on dynamic discovery SHOULD have some way of automatically sharing which realms are valid, and which are not. There are a number of possibilities here, and choosing the best one is up to each individual organization. Clients supporting dynamic discovery SHOULD require that servers use certificates from a private Certification Authority (CA). Clients MUST NOT automatically accept server certificates rooted from public CAs (e.g. as is done for web servers). Instead, clients MUST be configurable to use only a limited set of CAs. The default list of accepted CAs SHOULD be empty. Similarly, servers SHOULD require that clients use certificates from a private Certification Authority (CA). Servers MUST NOT accept client certificates rooted from a public CA. Servers which accept connections from dynamic discover are necessarily open to the Internet. Administrators SHOULD limit the source IP of allowed connections. Server SHOULD filter received packets by NAI, and close connections when the NAIs in incoming packets do not match the NAI(s) that the server expects. This mismatch indicates either a misconfigured or malicious client. Both clients and servers can send any data inside of a TLS tunnel. Implementations SHOULD take care to treat the data inside of a TLS tunnel as a potential source of attacks. Where multiple realms resolve to the same destination IP address, implementations MAY send packets for multiple realms across a connection to that IP address. Clients SHOULD use SNI to indicate which realm they are connecting to. Servers SHOULD present a certificate for the requested realm, instead of using a shared or "hosting" certificate which is owned by the hosting provider, and is used by multiple realms. Such certificate sharing decreases security, and increases operational costs. Where systems do not have a pre-defined list of allowed realms, implementations MUST support negative caching. That is, if the lookup for a particular realm fails, or a connection to that realm fails, then the implementation needs to cache that negative result for a period of time. This cache needs to be examined prior to any new lookup or connection being made. If there is an entry in the negative cache, then the server MUST skip the lookup or connection attempt, and instead return an immediate error. This negative cache time SHOULD be configurable. Other attacks are possible. If there are implementation bugs in a clients TLS library, an attacker could use dynamic discovery to cause the client to connect to a malicious server, and then use the server to attack the client. A malicious server could also slow down its TCP connection to engage client resources for extended periods of time. This process could even be done even before any TLS credentials are exchanged. In general, dynamic discovery is substantially different from normal application protocols which use TLS. There is substantial attack surface added by an unknown, and unauthenticated user who can cause a RADIUS client to connect to arbitrary systems under an attacker control. Dynamic discovery should be used with care, and only with substantial amounts of filtering on the NAI realms which are allowed, and only with stringent limits on the number of lookups, connection attempts, open connections, etc.

Minimize Personal Identifiable Information One approach to increasing RADIUS privacy is to minimize the amount of PII which is sent in packets. Implementers of RADIUS products and administrators of RADIUS systems SHOULD ensure that only the minimum necessary PII is sent in RADIUS. Where possible, identities should be anonymized (e.g. Section 2.4). The use of anonymized identities means that the the Chargeable-User-Identifier should also be used. Further discussion on this topic is below. Device information SHOULD be either omitted, or randomized. e.g. MAC address randomization could be used on end-user devices. The details behind this recommendation are the subject of ongoing research and development. As such, we do not offer more specific recommendations here. Information about the visited network SHOULD be replaced or anonymized before packets are proxied outside of the local organization. The attribute Operator-NAS-Identifier can be used to anonymize information about NASes in the local network. Location information ( SHOULD either be omitted, or else it SHOULD be limited to the broadest possible information, such as country code. For example, says:

• All OpenRoaming ANPs MUST support signaling of location information

This location information is required to include at the minimum the country code. We suggest the country code SHOULD also be the maximum amount of location information which is sent over third-party networks.

Creating Chargeable-User-Identity Where the Chargeable-User-Identity (CUI) is used, it SHOULD be unique per session. This practice will help to maximize user privacy, as it will be more difficult to track users across multiple sessions. Due to additional constraints which we will discuss below, we cannot require that the CUI change for every session. What we can do is to require that the home server MUST provide a unique CUI for each combination of user and visited network. That is, if the same user visits multiple networks, the home server MUST provide different CUIs to each visited network for that user. The CUI MAY be the same across multiple sessions for that user on one particular network. The CUI MAY be the same for multiple devices used by that user on one particular network. We note that the MAC address is likely the same across multiple user sessions on one network. Therefore changing the CUI offers little additional benefit, as the user can still be tracked by the unchanging MAC address. Never the less, we believe that having a unique CUI per session can be useful, because there is ongoing work on increasing user privacy by allowing more MAC address randomization. If we were to recommend that the CUI remain constant across multiple sessions, that would in turn negate much of the effort being put into MAC address randomization. One reason to have a constant CUI value for a user (or user devices) on one network is that network access providers may need to enforce limits on simultaneous logins. Network providers may also need to correlate user behavior across multiple sessions in order to track and prevent abuse. Both of these requirements are impossible if the CUI changes for every user session. The result is that there is a trade-off between user privacy and the needs of the local network. While perfect user privacy is an admirable goal, perfect user privacy may also allow anonymous users to abuse the visited network. The network would then likely simply refuse to provide network access. Users may therefore have to accept some limitations on privacy, in order to obtain network access. Although the CUI contents are not directly related to security, we still give recommendations for creating and managing of the CUI. We believe that these recommendations will help implementers satisfy the preceding requirements, while not imposing undue burden on the implementations. In general, the simplest way to track CUIs long term is to associate the CUI to user identity in some kind of cache or database. This association could be created at the tail end of the authentication process, and before any accounting packets were received. This association should generally be discarded after a period of time if no accounting packets are received. If accounting packets are received, the CUI to user association should then be tracked along with the normal accounting data. The above method for tracking CUI works no matter how the CUI is generated. If the CUI can be unique per session, or it could be tied to a particular user identity across a long period of time. The same CUI could also be associated with multiple devices. Where the CUI is not unique for each session, the only minor issue is the cost of the above method is that the association is stored on a per-session basis when there is no need for that to be done. Storing the CUI per session means that is it possible to arbitrarily change how the CUI is calculated, with no impact on anything else in the system. Designs such as this which decouple unrelated architectural elements are generally worth the minor extra cost. For creating the CUI, that process should be done in a way which is scalable and efficient. For a unique CUI per user, implementers SHOULD create a value which is unique both to the user, and to the visited network. There is no reason to use the same CUI for multiple visited networks, as that would enable the tracking of a user across multiple networks. Before suggesting a method for creating the CUI, we note that Section 2.1 defines the CUI as being of data type 'string' ( Section 3.5). Section 2.1 further suggests that the value of the CUI is interpreted as an opaque token, similar to the Class attribute ( Section 5.25). Some organizations create CUI values which use the Network Access Identifier (NAI) format as defined in . This format can allow the home network to be identified to the visited network, where the User-Name does not contain a realm. Such formats SHOULD NOT be used unless all parties involved have agreed to this behavior. The CUI SHOULD be created via a construct similar to what is given below, where "+" indicates concatenation: This construct has the following functional parameters.

• HASH
  • A cryptographic hash function. It is RECOMMENDED to use an HMAC instead of a hash function.

• Visited Network Data
  • Data which identifies the visited network. This data could be the Operator-Name attribute ( Section 4.1).

• User Identifier
  • The site-local user identifier. For tunneled EAP methods such as PEAP or TTLS, this could be the user identity which is sent inside of the TLS tunnel.

• Key
  • A secret known only to the local network. The key is generally a large random string. It is used to help prevent dictionary attacks on the CUI.

Where the CUI needs to be constant across multiple user sessions or devices, the key can be a static value. It is generated once by the home network, and then stored for use in further CUI derivations. Where the CUI needs to be unique per session, the above derivation SHOULD still be used, except that the "key" value will instead be a random number which is different for each session. Using such a design again decouples the CUI creation from any requirement that it is unique per session, or constant per user. That decision can be changed at any time, and the only piece which needs to be updated is the derivation of the "key" field. In contrast, if the CUI is generated completely randomly per session, then it may be difficult for a system to later change that behavior to allow the CUI to be constant for a particular user. If an NAI format is desired, the hash output can be converted to printable text, truncated if necessary to meet length limitations, and then an "@" character and a realm appended to it. The resulting text string is then in NAI form. We note that the above recommendation is not invertible. That is, given a particular CUI, it is not possible to determine which visited network or user identifier was used to create it. If it is necessary to use the CUI to look up a user, the home network needs to store the full set of CUI values which a user has been assigned. If this tracking is too complex for a network, it is possible to create the CUI via an invertible encryption process as follows: This construct has the following functional parameters.

• ENCRYPT
  • A cryptographically secure encryption function.

• Key
  • The encryption key. Note that the same key must not be used for more both hashing and encryption.

• Visited Network Data
  • Data which identifies the visited network. This data could be the Operator-Name attribute ( Section 4.1).

• User Identifier
  • The site-local user identifier. For tunneled EAP methods such as PEAP or TTLS, this could be the user identity which is sent inside of the TLS tunnel.

However, it is RECOMMENDED that HMAC based methods are used instead of methods based on reversible encryption. The intent is for CUI to leak as little information as possible, and ideally be different for every session. However, business agreements, legal requirements, etc. may mandate different behavior. The intention of this section is not to mandate complete CUI privacy, but instead to clarify the trade-offs between CUI privacy and business realities.

Privacy Considerations The primary focus of this document is addressing privacy and security considerations for RADIUS. Deprecating insecure transport for RADIUS, and requiring secure transport means that personally identifying information is no longer sent "in the clear". As noted earlier in this document, such information can include MAC addresses, user identifiers, and user locations. In addition, this document suggests ways to increase privacy by minimizing the use and exchange of PII.

Security Considerations The primary focus of this document is addressing privacy and security considerations for RADIUS. Deprecating insecure transports for RADIUS, and requiring secure transports, means that many historical security issues with the RADIUS protocol are mitigated. We reiterate the discussion above that any security analysis must be done on the system as a whole. It is not reasonable to put an expensive lock on the front door of a house while leaving the window next to it open, and then somehow declare the house to be "secure". Any approach to security based on a simple checklist is at best naive, and more truthfully is deeply misleading. At worst, such practices will decrease security by causing people to follow false security practices, and to ignore real security practices. Implementers and administrators need to be aware of the issues raised in this document. They can then make the best choice for their local network which balances their requirements on privacy, security, and cost. Only informed choices will lead to the best security.

Historical Considerations The BlastRADIUS vulnerability is the result of RADIUS security being a low priority for decades. Even the recommendation of that all clients add Message-Authenticator to all Access-Request packets was ignored by nearly all implementers. If that recommendation had been followed, then the BlastRADIUS vulnerability notification would have been little more than "please remember to set the require Message-Authenticator flag on all RADIUS servers." For MS-CHAP, it has not previously been deprecated for similar reasons, even though it has been proven to be insecure for decades. This continued use of MS-CHAP has likely resulted in the leaking of many users clear-text passwords.

Practical Implications This document either deprecates or forbids methods and behaviors which have been common practice for decades. While insecure practices have been viewed as tolerable, they are no longer acceptable.

IANA Considerations IANA is instructed to update the RADIUS Types registry, and the "Values for RADIUS Attribute 101, Error-Cause Attribute" sub-registry with the following addition:

Acknowledgements Thanks to the many reviewers and commenters for raising topics to discuss, and for providing insight into the issues related to increasing the security of RADIUS. In no particular order, thanks to Margaret Cullen, Alexander Clouter, and Josh Howlett. Many thanks to Nadia Heninger and the rest of the BlastRADIUS team, along with Heikki Vatiainen, for extensive discussions and feedback about the issue. The author is deeply indebted to the late Bernard Aboba for decades of advice and guidance.

Changelog

• 01 - added more discussion of IPsec, and move TLS-PSK to its own document,
• 02 - Added text on Increasing the Security of Insecure Transports
• 03 - add text on CUI. Add notes on PAP vs CHAP security
• 04 - add text on security of MS-CHAP. Rearrange and reword many sections for clarity.
• 05 - Rework title to deprecating "insecure practices". Clarifications based on WG feedback.
• 00 - adoption by WG.
• 01 - review from Bernard Aboba. Added discussion on accounting, clarified and re-arranged text. Added discussion of server behavior for missing Message-Authenticator
• 02 - BlastRADIUS updates.
• 03 - add delay Access-Reject, constant-time comparison, no routing protocol. Updated the text significantly and made it more consistent with the BlastRADIUS recommendations. Add "updates" other RFCs.
• 04 - updates with review from Fabian Mauchle
• 05 - merge in spelling fixes from Andrew Wood. Update and rewrite BlastRADIUS mitigations to make them clearer. Add section describing processes administrators can use to upgrade their networks.
• 06 - updates and clarifications based on reviews.
• 07 - move "review" text into draft-dekok-radext-review-radius

References Normative References 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. 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] This memo describes the requirements for a crypto-agility solution for Remote Authentication Dial-In User Service (RADIUS). This document is not an Internet Standards Track specification; it is published for informational purposes. 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. Deutsches Forschungsnetz | German National Research and Education Network Fondation Restena | Restena Foundation This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP or Datagram Transport Layer Security (DTLS) over UDP as the transport protocol. This enables encrypting the RADIUS traffic as well as dynamic trust relationships between RADIUS servers. The specification obsoletes the experimental specifications in RFC 6614 (RADIUS/TLS) and RFC 7360 (RADIUS/DTLS) and combines them in this specification. 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. 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. The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This memo provides information for the Internet community. This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS-CHAP version one (MS-CHAP-V1). This memo provides information for the Internet community. 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 defines a set of RADIUS (Remote Authentication Dial In User Service) attributes designed to support the provision of compulsory tunneling in dial-up networks. 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. This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session. This memo provides information for the Internet community. 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 updates the security considerations for the MD5 message digest algorithm. It also updates the security considerations for HMAC-MD5. This document is not an Internet Standards Track specification; it is published for informational purposes. The Remote Authentication Dial-In User Server (RADIUS) protocol has, until now, required the User Datagram Protocol (UDP) as the underlying transport layer. This document defines RADIUS over the Transmission Control Protocol (RADIUS/TCP), in order to address handling issues related to RADIUS over Transport Layer Security (RADIUS/TLS). It permits TCP to be used as a transport protocol for RADIUS only when a transport layer such as TLS or IPsec provides confidentiality and security. This document defines an Experimental Protocol for the Internet community. This document specifies a transport profile for RADIUS using Transport Layer Security (TLS) over TCP as the transport protocol. This enables dynamic trust relationships between RADIUS servers. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. The RADIUS protocol defined in RFC 2865 has limited support for authentication and encryption of RADIUS packets. The protocol transports data in the clear, although some parts of the packets can have obfuscated content. Packets may be replayed verbatim by an attacker, and client-server authentication is based on fixed shared secrets. This document specifies how the Datagram Transport Layer Security (DTLS) protocol may be used as a fix for these problems. It also describes how implementations of this proposal can coexist with current RADIUS systems. InkBridge Networks This document provides implementation and operational considerations for using TLS-PSK with RADIUS/TLS (RFC6614) and RADIUS/DTLS (RFC7360). The purpose of the document is to help smooth the operational transition from the use of the RADIUS/UDP to RADIUS/TLS. Wireless Broadband Alliance, Inc. Cisco Systems Intel Corporation SingleDigits Cisco Systems This document describes the Wireless Broadband Alliance's OpenRoaming system. The OpenRoaming architectures enables a seamless onboarding experience for devices connecting to access networks that are part of the federation of access networks and identity providers. The primary objective of this document is to describe the protocols that form the foundation for this architecture, enabling providers to correctly configure their equipment to support interoperable OpenRoaming signalling exchanges. In addition, the topic of OpenRoaming has been raised in different IETF working groups, and therefore a secondary objective is to assist those discussions by describing the federation organization and framework. Microsoft Corporation Extundo Microsoft Corporation Cisco Systems The Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the Protected Extensible Authentication Protocol (PEAP) Version 2, which provides an encrypted and authenticated tunnel based on transport layer security (TLS) that encapsulates EAP authentication mechanisms. PEAPv2 uses TLS to protect against rogue authenticators, protect against various attacks on the confidentiality and integrity of the inner EAP method exchange and provide EAP peer identity privacy. PEAPv2 also provides support for chaining multiple EAP mechanisms, cryptographic binding between authentications performed by inner EAP mechanisms and the tunnel, exchange of arbitrary parameters (TLVs), and fragmentation and reassembly. n.d. n.d. n.d. n.d. n.d. n.d. This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified. [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. The Remote Authentication Dial-In User Service (RADIUS) protocol is nearing exhaustion of its current 8-bit Attribute Type space. In addition, experience shows a growing need for complex grouping, along with attributes that can carry more than 253 octets of data. This document defines changes to RADIUS that address all of the above problems. RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets. This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. It lists TLS security properties provided by PSKs under certain assumptions, then it demonstrates how violations of these assumptions lead to attacks. Advice for applications to help meet these assumptions is provided. This document also discusses PSK use cases and provisioning processes. Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. The Extensible Authentication Protocol (EAP), defined in RFC 3748, provides a standard mechanism for support of multiple authentication methods. This document specifies the use of EAP-TLS with TLS 1.3 while remaining backwards compatible with existing implementations of EAP-TLS. TLS 1.3 provides significantly improved security and privacy, and reduced latency when compared to earlier versions of TLS. EAP-TLS with TLS 1.3 (EAP-TLS 1.3) further improves security and privacy by always providing forward secrecy, never disclosing the peer identity, and by mandating use of revocation checking when compared to EAP-TLS with earlier versions of TLS. This document also provides guidance on authentication, authorization, and resumption for EAP-TLS in general (regardless of the underlying TLS version used). This document updates RFC 5216. This memo describes an Extensible Authentication Protocol (EAP) method, EAP-pwd, which uses a shared password for authentication. The password may be a low-entropy one and may be drawn from some set of possible passwords, like a dictionary, which is available to an attacker. The underlying key exchange is resistant to active attack, passive attack, and dictionary attack. This document is not an Internet Standards Track specification; it is published for informational purposes. EAP-TTLS is an EAP (Extensible Authentication Protocol) method that encapsulates a TLS (Transport Layer Security) session, consisting of a handshake phase and a data phase. During the handshake phase, the server is authenticated to the client (or client and server are mutually authenticated) using standard TLS procedures, and keying material is generated in order to create a cryptographically secure tunnel for information exchange in the subsequent data phase. During the data phase, the client is authenticated to the server (or client and server are mutually authenticated) using an arbitrary authentication mechanism encapsulated within the secure tunnel. The encapsulated authentication mechanism may itself be EAP, or it may be another authentication protocol such as PAP, CHAP, MS-CHAP, or MS-CHAP-V2. Thus, EAP-TTLS allows legacy password-based authentication protocols to be used against existing authentication databases, while protecting the security of these legacy protocols against eavesdropping, man-in-the-middle, and other attacks. The data phase may also be used for additional, arbitrary data exchange. This memo provides information for the Internet community. This document specifies a means to find authoritative RADIUS servers for a given realm. It is used in conjunction with either RADIUS over Transport Layer Security (RADIUS/TLS) or RADIUS over Datagram Transport Layer Security (RADIUS/DTLS). In order to provide inter-domain authentication services, it is necessary to have a standardized method that domains can use to identify each other's users. This document defines the syntax for the Network Access Identifier (NAI), the user identifier submitted by the client prior to accessing resources. This document is a revised version of RFC 4282. It addresses issues with international character sets and makes a number of other corrections to RFC 4282. This document reviews the design and functionality of existing roaming implementations. Examples of cases where roaming capability might be required include ISP "confederations" and ISP-provided corporate network access support. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. This document describes a new Remote Authentication Dial-In User Service (RADIUS) attribute, Chargeable-User-Identity. This attribute can be used by a home network to identify a user for the purpose of roaming transactions that occur outside of the home network. [STANDARDS-TRACK] This document provides recommendations for the implementation of password-based cryptography, covering key derivation functions, encryption schemes, message authentication schemes, and ASN.1 syntax identifying the techniques. This document represents a republication of PKCS #5 v2.1 from RSA Laboratories' Public-Key Cryptography Standards (PKCS) series. By publishing this RFC, change control is transferred to the IETF. This document also obsoletes RFC 2898.

Best Practice Checklist In the interest of simplifying the above explanations, this section provides a short-form checklist of recommendations. Following this checklist does not guarantee that RADIUS systems are secure from all possible attacks. However, systems which do not follow this checklist are likely to be vulnerable to known attacks, and are therefore less secure than they could be.

• • Do not use RADIUS/UDP or RADIUS/TCP across the wider Internet
  Exposing user identifiers, device identifiers, and locations is a privacy and security issue.

• • Avoid RADIUS/UDP or RADIUS/TCP in other networks, too.
  It can take time to upgrade equipment, but the long-term goal is to entirely deprecate RADIUS/UDP.

• • Implement the BlastRADIUS mitigations
  Both Implementers and administrators should implement the mitigations in order to secure Access-Request packets.

• • Use strong shared secrets
  Shared secrets should be generated from a cryptographically strong pseudo-random number generator. They should contain at least 128 bits of entropy. Each RADIUS client should have a unique shared secret.

• • Minimize the use of RADIUS proxies.
  More proxies means more systems which could be compromised, and more systems which can see private or secret data.

• • Do not proxy from secure to insecure transports
  If user information (credentials or identities) is received over a secure transport (IPsec, RADIUS/TLS, TLS-based EAP method), then proxying the protected data over RADIUS/UDP or RADIUS/TCP degrades security and privacy.

• • Prefer EAP authentication methods to non-EAP methods.
  EAP authentication methods are better at hiding user credentials from observers.

• • For EAP, use anonymous outer identifiers
  There are few reasons to use individual identities for EAP. Identifying the realm is usually enough. Section 2.4 recommends that "@realm" is preferable to "anonymous@realm", which is in turn preferable to "user@realm".

• • Prefer using PAP over CHAP or MS-CHAP.
  PAP allows for credentials to be stored securely "at rest" in a user database. CHAP and MS-CHAP do not.

• • Do not use MS-CHAP outside of TLS-based EAP methods such as PEAP or TTLS.
  MS-CHAP can be cracked with minimal effort. The attack has been available for two decades.

• • Store passwords in "crypt"ed form
  Where is is necessary to store passwords, use systems such as PBKDF2 (.

• • Regularly update to the latest cryptographic methods.
  TLS 1.0 with RC4 was acceptable at one point in time. It is no longer acceptable. Similarly, the current cryptographic methods will at some point will be deprecated, and replaced by updated methods. Upgrading to recent cryptographic methods should be a normal part of operating a RADIUS server.

• • Regularly deprecate older cryptographic methods.
  Administrators should actively deprecate the use of older cryptographic methods. If no system is using older methods, then those methods should be disabled or removed entirely. Leaving old methods enabled makes the server more vulnerable to attacks.

• • Send the minimum amount of information which is needed,.
  Where proxying is used, it is a common practice is to simply forward all of the information from a NAS to other RADIUS servers. Instead, the proxy closest to the NAS should filter out any attributes or data which are not needed by the "next hop" proxies, or by the home server.