|
> Not if the RADIUS server has an administrative flag saying "this NAS > supports better security". > > Once that flag is set, then any down-grade attack disappears. In a very large deployment (e.g. thousands of NASes) keeping track of which ones support the new capabilities is non-trivial. > The client should also have a per-server flag saying "negotiated > secure RADIUS". Once that flag is set, it refuses to use legacy RADIUS. This requires that the RADIUS client population can be enumerated and clearly identified. In a deployment that has a list of RADIUS clients at fixed IP addresses, that requirement can be met. In other situations, that's not as obvious. > > It seems to me that the only way to completely address this is by having > > the NAS indicate support *within RADIUS*. > > Use an insecure protocol to negotiate a secure one... hmmm... For this purpose, MD5 is not "insecure" until it is possible to forge RADIUS messages in near real-time. Even with all the attacks against WEP, the progression from cracking it in weeks to minutes took place over a significant time period. > My suggestion in the DTLS document is for the NAS to simply start > using the better security method. Once the NAS has been authenticated, > the "NAS supports better security" flag is set, and legacy RADIUS > becomes impossible. That represents the end state where all legacy NASes have been replaced. > > Use of dynamic discovery doesn't help without DNSSEC, since an attacker > > can forge the RRs to force a downgrade. > > Legacy RADIUS doesn't use RR's. If the client is found via RR's, it > MUST use the newer, more secure, solution. But that doesn't imply that the RRs are retrieved securely, so dynamic discovery doesn't address the downgrade issue. In fact, one could argue that the introduction of (insecure) dynamic discovery complicates the security analysis considerably. |