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

From: Stefan Winter <[email-masked]>
Date: Fri, 10 Jul 2009 14:58:52 +0200

Hi,

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

While I was working on the profiles to identify a peer in TLS/DTLS, I
started wondering how in practice the above validation of support for a
peer can happen reliably.

Let's assume the peer was previously only supporting plain RADIUS, and
was thus identified by the tuple

(IP,Shared-secret)

Now, it gets a firmware upgrade and supports TLS-PSK. It is then
identified as

(TLS-PSK-Identity, key)

For the server who receives requests it looks like client
RADIUS/(IP,Shared-secret) became silent, while there was a new client
from the same source IP address identifying itself as
RadSec/(TLS-PSK-Identity, key); TLS-PSK-Identity and the old, configured
IP are not necessarily identical. How does the server know these two are
the same logical entity? Having the same source IP address could be due
to two independent instances of RADIUS software running on the same device.

One could set TLS-PSK-Identity == IP and Shared-secret == PSK as an
administrative action. Should we define this as suggested upgrading
path, and subsequently define that under these circumstances, two peers
should be regarded as logically the same?

The same question applied to TLS with certificates and a PKI behind:

Should we define: if ( IP == subjectAltName:IPAddr) && (cert valid and
from "good" CA) => same logical entity as the previous (IP,shared secret)?

The situation looks a bit more dim when considering TLS with
certificates and fingerprints for validation... I don't think any
automatic validation that the same peer is present can happen; in such
cases, manual configuration of the new capabilities of the client is
necessary, i.e. feeding the expected fingerprint into the server
configuration.

Greetings,

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

-- 
Stefan WINTER
Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche
6, rue Richard Coudenhove-Kalergi
L-1359 Luxembourg

Tel: +352 424409 1
Fax: +352 422473

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

---

From: Alan DeKok <[email-masked]>
Date: Tue, 14 Jul 2009 16:25:59 +0200

> Now, it gets a firmware upgrade and supports TLS-PSK. It is then

  Yes and no.  If this configuration *replaces* the previous one, then
there is no problem.  The old configuration is gone, and all packets
must use TLS-PSK with the above identity and key.

  If this configuration is in *addition* to the old one, then the old
one can be automatically deleted once TLS-PSK has been negotiated.

> to two independent instances of RADIUS software running on the same device.

  Tough.  This is addressed in the DTLS draft: there SHOULD be only one
source of packets from the machine.  If this means running a local
proxy, so be it.

  The ability to accept *both* legacy && TLS authentication from the
same IP is nothing more than a down-bidding attack.  It's wrong, and
should be forbidden.

> administrative action.

  Absolutely not!  The legacy shared secret MUST NOT be the same as the
PSK!  Othewise, an attacker could break MD5 to get the shared secret,
and then leverage that to authenticate via "strong" crypto.

  The above configuration needs to be forbidden in *very* strong words.

> from "good" CA) => same logical entity as the previous (IP,shared secret)?

  No.  Tying a certificate to an IP address negates much of the benefit
of using certificates.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Wed, 15 Jul 2009 11:17:57 +0200

Bernard Aboba wrote:
> [BA] This makes sense to me.  But beyond that -- the upgrade scenario we had
> discussed involved upgrading the server first.  So assuming that the server
> supports the new crypto-agile functionality, and the RADIUS client has also
> been upgraded, why would the RADIUS client still need to send legacy RADIUS
> packets to the server? It seems like that would only happen if the RADIUS
> client were mis-configured,  or the implementation was broken, no?

  Yes.  While I can see some systems upgrading clients before servers,
this practice should be discouraged.

> That said, there still may be some operational annoyance associated with
> having "old" and "new" RADIUS client configurations on the server,
> effectively doubling the NAS configuration.  It would be nice to be able to
> tie the "old" and "new" clients together somehow, so as to be able to remove
> configuration info on "old" NASes that have long since been upgraded.  But
> this seems like more of an operational hassle than a requirement, I think. 

  Yes.  Most servers already have per-NAS configuration.  I would
suggest something like:

  1) define client by IP, secret (and server-specific stuff)
  2) add TLS data to above client definition (PSK, certs, etc.)
  3) delete IP && secret configuration from client definition

  Alan DeKok.