Re: [radext] I-D Action: draft-ietf-radext-tls-psk-03.txt

[Alan DeKok <[e-mail]>]

On Sep 18, 2023, at 1:01 AM, Bernard Aboba <[e-mail]> wrote:
> [BA] A more general admonition is better given the past (and most likely future) problems. 

  Sure.  Perhaps MUST only use TLS 1.3 or later, as it already has provisions for tying the PSK to the TLS version.

> The more basic problem is that secure RADIUS could take more than a decade to deploy, and I'm concerned that we could be into the post-quantum era before we're even at the half-way point.  AFAICT, the basic protection mechanism, (D)TLS, should be fine; but credentials (such as PSKs installed for use with TLS 1.3) won't be.
> 
> This makes me wonder whether there is a critical element missing - a credential provisioning mechanism.  For example, a mechanism to use a TLS 1.3 PSK to obtain a post-quantum credential usable with TLS 1.4. 

  We've been trying to address that for 20+ years IIRC.  I think the good news is that the opposition to these activities seems to have died down.  That makes it easier to solve these problems.

  There may be ways to do this provisioning automatically over RADIUS, but I'm wary of designing yet another provisioning system.  We could use existing protocols (e.g. EST RFC 7030), but the NASes typically have minimal resources, and minimal UI.

> Secure RADIUS will most likely be a "forklift" (or "dump truck") upgrade.  NAS devices approaching (or past) end-of-life may not have a secure upgrade available.  So where the service is still viable (e.g. enterprise Wifi), new equipment will need to be purchased and provisioned. This typically runs on a 7 year depreciation cycle.  In situations like that, customers tend to become very upset if the equipment becomes obsolete before the end of the depreciation period, because this means that their companies need to "write off" the equipment, which goes direct to the bottom line.  Very often, if a major transition can be envisaged (e.g. IPv4 to IPv6), customers will impose requirements to prevent the purchase of equipment that could become obsolete prior to the end of the depreciation lifetime. 

  The good news is that many NASes already support TLS, as they often have web UIs.  So the only next step here is to support RADIUS over TLS.  And many already do that.

  I think one way to help that is to push the "deprecation" document.  If vendors are embarrassed by having known insecurities, then it's more likely that they will upgrade.

> So it's nice to have a story to tell that can reassure them. 

  I agree.

  I think also that if we can, it is highly beneficial to solve this problem now.  That way we don't need to do it again later.  And implementors can just fix their systems once, and then get the benefit of the updates without needing to wait a decade.

  Alan DeKok.