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

[Alan DeKok <aland@deployingradius.com>]

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.

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