Re: Open issues on the Crypto-Agility Requirements draft

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> 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.

  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.

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

  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.

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

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

  The server can keep a flag saying "NAS uses secure RADIUS".  If it
sees a legacy RADIUS packet from the NAS, it knows something is wrong.
It can return an Access-Reject, or simply discard the packet.  This
protects the server.

  The client should also have a per-server flag saying "negotiated
secure RADIUS".  Once that flag is set, it refuses to use legacy RADIUS.

  Alan DeKok.

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>