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

[Alan DeKok <aland@deployingradius.com>]

Stefan Winter wrote:
> 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)

  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.

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

  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.

> One could set TLS-PSK-Identity == IP and Shared-secret == PSK as an
> 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.

> Should we define: if ( IP == subjectAltName:IPAddr) && (cert valid and
> 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.

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