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

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Jun 2009 14:04:02 -0700

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

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 28 Jun 2009 14:34:37 -0700

Pasi seems to be making a valid point here. 

Once MD5 is compromised, it will not be possible to avoid bidding down or other attacks. 

A proposal is to state explicitly that protection against bidding down is only possible prior to MD5 compromise.  After that, the only protection is requiring use of improved algorithms, by policy. 

From: [email-masked]
To: [email-masked]
Subject: Crypto-agility requirements:  Compromise of Legacy Shared Secret (from Issue 303)
Date: Sun, 28 Jun 2009 14:04:02 -0700

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Jun 2009 12:00:39 +0200

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

> 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>