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

[Stefan Winter <stefan.winter@restena.lu>]

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