From aland@deployingradius.com Mon Nov 13 15:00:15 2023 Return-Path: X-Original-To: radext@ietfa.amsl.com Delivered-To: radext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B06C15152C for ; Mon, 13 Nov 2023 15:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eZntl4du7Yf for ; Mon, 13 Nov 2023 15:00:13 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D7C6C151099 for ; Mon, 13 Nov 2023 15:00:12 -0800 (PST) Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id CBC154EF; Mon, 13 Nov 2023 23:00:08 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) From: Alan DeKok In-Reply-To: Date: Mon, 13 Nov 2023 18:00:07 -0500 Cc: radext@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <9BCDBFAB-A444-42BD-9419-72306CBFB43C@deployingradius.com> References: To: Bernard Aboba X-Mailer: Apple Mail (2.3696.120.41.1.1) Archived-At: Subject: Re: [radext] Review of draft-ietf-radext-deprecating-radius X-BeenThere: radext@ietf.org X-Mailman-Version: 2.1.39 Precedence: list List-Id: RADIUS EXTensions working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2023 23:00:15 -0000 On Nov 10, 2023, at 2:15 AM, Bernard Aboba = wrote: >=20 > 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.=C2=B6 >=20 > [BA] This statement seems like a good summary. It should be moved = earlier in the document and echo'd in the abstract.=20 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 >=20 > "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.=C2=B6"= =20 >=20 > [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 >=20 > 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. >=20 > [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...=C2=B6 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 >=20 > "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.=C2=B6 >=20 > It is reasonable to expect that new research can further break MD5, = but also that such research may not be publicly available." >=20 > [BA] I'd probably ask SECDIR to review this section if you are going = to make recommendations beyond those made in RFC 6151.=20 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 >=20 > 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.=20 I'll add a note earlier in the document, but I think it's too long to = go into the introduction. > Section 4 >=20 > "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.=C2=B6" >=20 > [BA] I think you need to clarify that this paragraph refers to RADIUS = attributes, not to TLS-protected transport in EAP-TTLS.=20 It also can apply if the TTLS tunnel is terminated, and the inner data = proxied. I'll add some text. > Section 5.1 >=20 > "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." >=20 > [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: =20 True. How about "believed" to be secure, and then NOT RECOMMENDED = even then. > Section 6 >=20 > "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.=C2=B6" >=20 > [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.=20 OK. > Section 7.3 >=20 > "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.=C2=B6" >=20 > [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.=20 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.=C2=B6" >=20 > [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 >=20 > 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.=20 7.4 is MS-CHAP? > Section 7.5 >=20 > "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." >=20 > [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.=20 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.=20 I've added text to address it. > Comments on other text >=20 > "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."=C2=B6 >=20 > [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. >=20 > 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.=20 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." >=20 > [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? =20 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."=C2=B6 >=20 > [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. =20 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." >=20 > [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.=20 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." >=20 > [BA] "be be" -> "be"=20 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)."=C2=B6 >=20 > [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. 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."=20 >=20 > [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."=C2=B6 >=20 > [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.