|
I would remind people that the focus here is on the requirements, not the solution. One of the reasons we do requirements documents is to determine when we are done. The requirements document has already taken so long that we are now in danger of finishing work on solutions that may not meet the requirements. So we need to ratchet up the rate of progress, so as to finish this document in the next few months. One big issue that we need to close on his the requirements with respect to downgrade attacks. Assuming that legacy RADIUS is still supported in a NAS deployment (likely to be true for a long time), then it is possible for an attacker to attempt to convince the RADIUS server (which we presume has been upgraded) to utilize legacy RADIUS with MD5 security. It seems to me that the only way to completely address this is by having the NAS indicate support *within RADIUS*. Use of dynamic discovery doesn't help without DNSSEC, since an attacker can forge the RRs to force a downgrade. Use of transport wrappers can't address it either if we assume that attackers have the ability to cause arbitrary packets to be lost, and that the NAS will drop down to ordinary RADIUS in the situation that transmission layer security doesn't generate a response. However, if we assume that MD5 hasn't yet been cracked, then even if the attacker convinces the NAS to use legacy RADIUS, if there is an attribute that annouces what the NAS is capable of, when the server receives the Access-Request, it can determine that something has gone wrong (e.g. client claims to support crypto-agility, but the Access-Request didn't use it). As Glen pointed out, if sensitive information is provided in the Access-Request, you still have a problem (e.g. User-Password attribute could expose the user password). But at least the issue can be discovered after the fact. |