Re: Crypto-agility requirements: Compromise of Legacy Shared Secret (from Issue 303)

[Alan DeKok <aland@deployingradius.com>]

Bernard Aboba wrote:
> It seems to assume that for this particular peer, the administrator
> has configured two different shared secrets (one for the current
> security mechanisms, another for the new ones), but has not configured
> whether to use the old or new mechanisms (with this particular peer),
> and instead, that is negotiated somehow.

  I agree.  This *dual* configuration should be discouraged.  Most of
the time the peers will be using *either* legacy RADIUS, or a
crypto-agile solution.  The only time both systems can be used is when
one peer does not know the other peers capabilities.

  As soon as a peer validates that a crypto-agile solution is supported,
the legacy RADIUS configuration MUST be disabled or discarded.

  This limits the attack to forcing the peers to continue with RADIUS
after a crypto-agile solution is available.  This attack is therefore no
worse than existing RADIUS.

> If the attacker knows the legacy shared secret, and has complete
> control over the communication channel (and in particular, can drop
> messages going from A to B), then it seems the attacker will be
> indistinguishable from a valid peer that supports only the legacy
> mechanisms (and does not know the new shared secret), and detecting
> bidding down will not be possible.

  Yes.

  This attack can be prevented by having an administrator configure the
peer to *require* a crypto-agile solution.

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