Re: [radext] BoF request for IETF 115

[Alan DeKok <[e-mail]>]

On Sep 24, 2022, at 2:12 AM, Alexander Clouter <[e-mail]> wrote:
> Trying to make bullet proof an environment where someone wants to use their pets name as a PSK is probably a battle we are going to lose. In fairness, it is also a choice the user made for reasons that make sense to them and their local environment...it may not be correct but I am not sure there is anything anyone can do there.

  Many moons ago Bob Moscowitz and I had a "client kickstart" draft at IETF 58 (draft-moskowitz-RADIUS-Client-Kickstart-02.txt).  That may have addressed the issue, but it never got traction.

  Any new automated method to provision secure PSKs could require substantial changes to RADIUS system workflows and UIs.  That rules out most ideas.

  In the end, the issue of securely provisioning PSKs is too often a human issue.  Which makes it very difficult to solve.

  So we can give advice on what to do.  It's the only thing which we know isn't wrong, and which can be implemented.

  e.g. "get 80+ bits of randomness, base32-encode it, and take 16 characters".  That gets you 80 bits of entropy, which should be enough.  Plus it's ASCII.  And small enough that most NAS equipment will support 16-character strings.

  TBH, we should just deprecate PSKs.  Perhaps allow the use of a PSK, but mark it as NOT RECOMMENDED.  And require that all implementations MUST support client certificates.  That won't solve the problem, but it will at least embarrass insecure implementations.

  Alan DeKok.