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

[Bernard Aboba <[e-mail]>]

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.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-1-15>

[BA] This statement seems like a good summary. It should be moved earlier
in the document and echo'd in the abstract.


Section 3

"Further, MD5 has been broken for over a decade, as summarized in [RFC6151
<https://www.rfc-editor.org/info/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.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-3-2>
"

[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:

   MD5 is no longer acceptable where collision resistance is required
   such as digital signatures.  It is not urgent to stop using MD5 in
   other ways, such as HMAC-MD5; however, since MD5 must not be used for
   digital signatures, new protocol designs should not employ HMAC-MD5.
   Alternatives to HMAC-MD5 include HMAC-SHA256 [HMAC] [HMAC-SHA256] and
   [AES-CMAC] when AES is more readily available than a hash function.

Section 3.1

There are clear privacy and security information with sending user
identifiers, and user locations [RFC5580
<https://www.rfc-editor.org/info/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...¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-3.1-2>

Section 3.2

"Attacks on MD5 are summarized in part in [RFC6151
<https://www.rfc-editor.org/info/rfc6151>]. While there have not been many
new attacks in the decade since [RFC6151
<https://www.rfc-editor.org/info/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.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-3.2-1>

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.

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.

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.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-4-2>
"

[BA] I think you need to clarify that this paragraph refers to RADIUS
attributes, not to TLS-protected transport in EAP-TTLS.

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:

   "6.2 It is highly desirable that Internet carriers protect the privacy
   and authenticity of all traffic, but this is not a requirement of the
   architecture.  Confidentiality and authentication are the
   responsibility of end users and must be implemented in the protocols
   used by the end users. Endpoints should not depend on the
   confidentiality or integrity of the carriers. Carriers may choose to
   provide some level of protection, but this is secondary to the
   primary responsibility of the end users to protect themselves."

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.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-6-1>
"

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

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.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-7.3-1>
"

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

"It is therefore RECOMMENDED that administrators use PAP in preference to
CHAP or MS-CHAP.¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-7.3-9>
"

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

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.

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.

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.


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."¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-1-7>

[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?

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


"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?


"Even if a stronger packet signature method was used as in [RFC6218
<https://www.rfc-editor.org/info/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."¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-1-9>


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

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


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

"MS-CHAP ([RFC2433 <https://www.rfc-editor.org/info/rfc2433>] and [RFC2759
<https://www.rfc-editor.org/info/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
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#ms-chap>
)."¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-1-11>


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


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


"And even when TLS-based EAP methods are used, implementations have
historically often skipped certificate validation, leading to password
compromise ([SPOOFING
<https://networkradius.com/articles/2021/08/04/wifi-spoofing.html>]). 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."¶
<https://datatracker.ietf.org/doc/html/draft-ietf-radext-deprecating-radius#section-1-14>

[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?