Re: [radext] Review of draft-ietf-radext-deprecating-radius

[Alan DeKok <[e-mail]>]

On Nov 10, 2023, at 2:15 AM, Bernard Aboba <[e-mail]> wrote:
> 
> 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 insecure uses of RADIUS, and mandates the use of secure TLS-based transport layers. We also discuss related security issues with RADIUS, and give many recommendations for practices which increase security and privacy.¶
> 
> [BA] This statement seems like a good summary. It should be moved earlier in the document and echo'd in the abstract. 

  There's already a similar statement in the abstract, but this text is better.  I'll also move it earlier in the document,

> Section 3
> 
> "Further, MD5 has been broken for over a decade, as summarized in [RFC6151]. For traffic sent across the Internet, no protocol should depend on MD5 for security. Even if MD5 was not broken, computers have gotten substantially faster in the past thirty years. This speed increase makes it possible for the average hobbyist to perform brute-force attacks to crack even seemingly complex shared secrets.¶" 
> 
> [BA] I would suggest quoting from RFC 6151, rather than using more vague terms like "broken".  Overall though, RFC 6151 gives more modest advice, so I think you need to refer to other arguments:

  I'll clarify and add some text.  I've added a quote from 6151 earlier in the document, so I don't think it's necessary to repeat that here.

> Section 3.1
> 
> There are clear privacy and security information with sending user identifiers, and user locations [RFC5580] in clear-text across the Internet. As such, the use of clear-text protocols across insecure networks is no longer acceptable.
> 
> [BA] Maybe you can cite some other documents (e.g. IAB privacy guidance) to justify the last sentence? Certainly, leaking 15-meter accurate location seems like a very bad idea...¶

  I'll add references to 6973 "Privacy Considerations for Internet Protocols", and 6280 "Architecture for Location and Location Privacy in Internet Applications"

> Section 3.2
> 
> "Attacks on MD5 are summarized in part in [RFC6151]. While there have not been many new attacks in the decade since [RFC6151] was published, that does not mean that further attacks do not exist. It is more likely that no one is looking for new attacks.¶
> 
> It is reasonable to expect that new research can further break MD5, but also that such research may not be publicly available."
> 
> [BA] I'd probably ask SECDIR to review this section if you are going to make recommendations beyond those made in RFC 6151. 

  I'm not trying to make recommendations, but to explain that the attacks only get better over time.  I'll just delete the last sentence.

> Section 3.3
> 
> I might put this section earlier, since it seems to be the most significant vulnerability that has advanced since publication of RFC 6421 and 6151. 

   I'll add a note earlier in the document, but I think it's too long to go into the introduction.

> Section 4
> 
> "In conclusion, if a User-Password, or CHAP-Password, or MS-CHAP password has been sent over the Internet via RADIUS/UDP or RADIUS/TCP in the last decade, you should assume that underlying password has been compromised.¶"
> 
> [BA] I think you need to clarify that this paragraph refers to RADIUS attributes, not to TLS-protected transport in EAP-TTLS. 

  It also can apply if the TTLS tunnel is terminated, and the inner data proxied.  I'll add some text.

> Section 5.1
> 
> "RADIUS/UDP and RADIUS/TCP MUST NOT be used outside of secure networks. A secure network is one which is known to be safe from eavesdroppers, attackers, etc."
> 
> [BA] What network is known to be safe in this way? RFC 1985 Section 6 makes it clear that endpoints should not depend on such claims:  

  True.  How about "believed" to be secure, and then NOT RECOMMENDED even then.

> Section 6
> 
> "Our best guess is that at the time of this writing, there could be in the order of hundreds of thousands, if not millions of RADIUS/UDP devices in daily use.¶"
> 
> [BA] The access point market is multiple billion $ today and growing at a healthy rate. Since virtually every access point sold supports RADIUS and every enterprise AP uses RADIUS, we can definitely say that there are millions of legacy RADIUS-enabled devices. 

  OK.

> Section 7.3
> 
> "Some organizations may desire to increase the security of their network by using alternate authentication methods such as CHAP or MS-CHAP, instead of PAP. These attempts are largely misguided. If simple password-based methods must be used, in almost all situations, the security of the network as a whole is increased by using PAP in preference to CHAP or MS-CHAP. The reason is found through a simple risk analysis, which we explain in more detail below.¶"
> 
> [BA] This paragraph talks about "authentication methods" rather than RADIUS attributes and as such is potentially confusing.  EAP-TTLS carries CHAP/MS-CHAP/PAP attributes within a TLS tunnel, and so unless EAP-TTLS is terminated and proxied in the clear, you won't see CHAP/MS-CHAP/PAP attributes in RADIUS, only within a TLS tunnel. The same is true of PEAP with EAP-MSCHAPv2. 

  The issue is less that an attacker can see the data "in transit", than how the network stores passwords.  I'll try to clarify the text.

  i.e. you can use CHAP over EAP-TTLS over RADIUS/TLS.  But that means *all* passwords are stored in clear-text.  An attacker who gets access to the DB can steal all clear-text passwords.

  In contrast, using PAP means that passwords are *temporarily* clear-text in the memory of the RADIUS server.  An attacker who gets access to the DB gets crypt'd passwords, which are much less useful.

  I'll rewrite that section to clarify the text.

> "It is therefore RECOMMENDED that administrators use PAP in preference to CHAP or MS-CHAP.¶"
> 
> [BA] I think you need to distinguish the usage of PAP/CHAP/MS-CHAP in EAP-TTLS (where the RADIUS attributes can appear when "naked proxies" are used) and uses in other EAP methods where those RADIUS attributes aren't used.

  No, see above.

> Section 7.4
> 
> This section relates to EAP, not to the use of RADIUS attributes, so it is somewhat confusing.  IMHO, it would make more sense to discuss the situations in which you will see PAP/CHAP/MS-CHAP attributes on the wire so that people can avoid them. 

  7.4 is MS-CHAP?

> Section 7.5
> 
> "it is RECOMMENDED to use EAP instead of PAP, CHAP, or MS-CHAP. If passwords are used, they can be can be protected via TLS-based EAP methods such as EAP-TTLS or PEAP."
> 
> [BA] The first sentence is good advice, and probably should be moved earlier in the document, since it motivates discussion of vulnerabilities in the CHAP/PAP/MS-CHAP RADIUS attributes. 

  Will do.

> The second sentence is problematic, since EAP-TTLS if terminated on a "naked proxy" will send PAP/CHAP/MS-CHAP attributes in the clear, exactly the problem you're trying to avoid. 

  I've added text to address it.

> Comments on other text
> 
> "While MD5 has been broken, it is a testament to the design of RADIUS that there have been (as yet) no attacks on RADIUS Authenticator signatures which are stronger than brute-force."¶
> 
> [BA] RFC 6151 seems to suggest attacks stronger than brute force, no?  Overall, I'd suggest that this sentence be deleted. The use of the term "broken" needs additional clarification, perhaps via quotes from RFC 6151.  The paragraph that follows provides additional detail, but as it stands it isn't clear that this sentence is referring to those considerations, or some of the weaknesses described in RFC 6151 or other documents.
> 
> RFC 6421 Section 3 details the known weaknesses as of 2011, and provides references. You refer to it early on, so the reader is expecting an update on newer weaknesses and threats. Have there been advances in MD5 collisions and cryptographic weaknesses beyond those described in RFC 6421?

  No.  I suspect everyone just stopped looking.

> RFC 3579 describes attacks on MD5 stream ciphers that are stronger than brute-force, such as repeating nonces, known plaintext attacks, etc. 

  OK.

> "However, the problems with MD5 means that if a someone can view unencrypted RADIUS traffic, even a hobbyist attacker can crack all possible RADIUS shared secrets of eight characters or less. Such attacks can also result in compromise of all passwords carried in the User-Password attribute."
> 
> [BA] I think you need to clarify what "view unencrypted RADIUS traffic" means. Are you referring to a RADIUS packet not protected by (D)TLS?  Or are you referring to a conventional RADIUS packet without protected attributes?  

  RADIUS/UDP or RADIUS/TCP. I'll clarify.

> "Even if a stronger packet signature method was used as in [RFC6218], it would not fully address the issues with RADIUS. Most information in RADIUS is sent in clear-text, and only a few attributes are hidden via obfuscation methods which rely on more "ad hoc" MD5 constructions. The privacy implications of this openness are severe."¶
> 
> [BA] The term "signature" with RADIUS doesn't seem quite right, since there is no public cryptography involved, just a hash, right?  Can you be more specific which "issues with RADIUS" are being referred to here?  The protocol has so many vulnerabilities, I wasn't sure whether you were referring to attacks on the RADIUS shared secret, the inadequacy of the MD5 stream cipher, potential issues with collissions or some other inadequacy.  

  I'll see if I can clarify.  2865 refers to this process as "signing" or a "signature".  Any other phrasing seems more awkward.

> "When RADIUS/UDP is used across the public Internet, the location of individuals can potentially be tracked in real-time (usually 10 minute intervals), to within 15 meters. Their devices can be identified, and tracked."
> 
> [BA] I think you want to specifically state the access mechanisms that permit 15-meter accuracy (e.g. WiFi) and the role of Wifi MAC address to location lookups that made this kind of realtime tracking possible. The accuracy was is course much worse for dialup or VPNs. 

  OK.  I'll add some text on AP MAC to location databases, too.

> "Any passwords they send via the User-Password attribute can be be compromised. Even using CHAP-Password offers minimal protection, as the cost of cracking the underlying password is similar to the cost of cracking the shared secret."
> 
> [BA] "be be" -> "be" 

  Fixed.

> "MS-CHAP ([RFC2433] and [RFC2759]) is significantly worse for security, as it can be trivially cracked with minimal resources even if the shared secret is not known (Section 7.4)."¶
> 
> [BA] A bit more detail might help here. MS-CHAP attributes were deprecated with the advent of PEAP/EAP-MSCHAPv2, so they typically will only be encountered in legacy dialup networking or when EAP-TTLS is proxied.  EAP-TTLS proxying can send CHAP, MS-CHAP and even PAP attributes in the clear, which creates some unique problems.

  <cough>  Cloud identity providers still sometimes use bare PAP / CHAP / MS-CHAP.

  I've added some text clarifying this.

> "For example, some authentication methods such EAP-TLS, EAP-TTLS, etc. allow for User-Name privacy and for more secure transport of passwords via the use of TLS." 
> 
> [BA] Given the previous concerns about CHAP, MS-CHAP, etc. it seems odd not to cover the extra vulnerabilities introduced by EAP-TTLS proxying, which opens up security vulnerabilities that do not exist with other TLS-based EAP methods. Without that additional coverage the statement is somewhat misleading.

  I've added a section on TLS-based EAP methods and RADIUS/TLS.  The security analysis is somewhat similar.

  i.e. using PAP / CHAP / MS-CHAP over TTLS and then proxying the inner tunnel data isn't much different than using PAP / CHAP / MS-CHAP over RADIUS/TLS, then then proxying to RADIUS/UDP.

  TTLS uses channel binding to create the CHAP / MS-CHAP challenges, so it's a *bit* more difficult to proxy the inner data, but not impossible.

> "And even when TLS-based EAP methods are used, implementations have historically often skipped certificate validation, leading to password compromise ([SPOOFING]). In many cases, users were not even aware that the server certificate was incorrect or spoofed, which meant that there was no way for the user to detect that anything was wrong. Their passwords were simply handed to a spoofed server, with little possibility for the user to take any action to stop it."¶
> 
> [BA] Reading this paragraph lead me to wonder whether the problems with skipped certificate validation will also become common with RADIUS over (D)TLS. Or is there reason to believe that this problem will become less common with secure RADIUS?

  No.  :(

  Alan DeKok.