In Issue 303, Pasi Eronen said:
"Compromise of legacy shared secret:
Section 4.2 says "Crypto-agility solutions MUST avoid security
compromise, even in situations where the existing cryptographic
algorithms utilized by RADIUS implementations are shown to be weak
enough to provide little or no security (e.g. in event of compromise
of the legacy RADIUS shared secret). Included in this would be
protection against bidding down attacks."
If interpreted literally, this requirement could be very difficult
to meet (perhaps impossible).
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.
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.
Preventing bidding down in less extreme cases of compromise is of
course both possible and desirable (e.g. if the algorithms are just
weak but not breakable in real time, or if the attacker doesn't have
complete control over the communications). And the administrator could
always configure just the "new shared secret", if he/she knows that
the peer supports it.
"
|