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

[Alan DeKok <[e-mail]>]

On Sep 18, 2023, at 11:25 AM, Bernard Aboba <[e-mail]> wrote:
> [BA] Yes, but most likely it's TLS 1.2 or earlier.  The time between 1.2 and 1.3 was so long that a lot of equipment end-of-life'd before 1.3 came out, but is still operating.  That equipment will never get a TLS 1.3 upgrade, which means that when TLS 1.2 is deprecated it will need to be retired. As an example,  for enterprise WiFi, there are probably many 802.11AC deployments out there from the mid to late 2010s that are now at or nearing end-of-life and therefore may not get a TLS 1.3 upgrade. Will be interesting to see if those devices will be offered an upgrade to secure RADIUS with TLS 1.2.  Often vendors limit those upgrades to newer equipment. 

  I think then mandating TLS 1.3 is best then.  If it takes a while for people to add TLS-PSK, there are few reasons to allow TLS 1.2.

  We can also hope that RADIUS/1.1 is getting implemented.  And perhaps also some provisioning.

> [BA] Yes, it's useful to think of the set of functionality that you want an organization like WiFi Alliance to certify.  It's not just secure RADIUS.  Ideally, I think customers want is equipment (and RADIUS servers) that can continue to operate securely, through transitions from TLS 1.3 to 1.4 and post-quantum crypto.  That's a tall order, but I think we're potentially entering a period where the pace of transitions could become very difficult to navigate. 

  I think that's the driving factor here.  We're fixing things, we might as well fix all of the things.

  So the next question is how to solve the bootstrapping problem.  Maybe we can dust off an old draft from Bob Moskowitz and I:

https://datatracker.ietf.org/doc/html/draft-moskowitz-radius-client-kickstart-01

  That uses SNMP, but a similar approach is used in a number of places.

  Or, perhaps approach similar to this:

https://datatracker.ietf.org/doc/html/draft-friel-tls-eap-dpp-05

https://www.ietf.org/archive/id/draft-ietf-emu-bootstrapped-tls-03.html

  If RADIUS servers already need to support these for EAP, then the framework will be there for doing something similar at the RADIUS/TLS layer.

  Those document describe how a TLS connection can be established based on a raw public / private key.  The application data can then contain some ??? extra magic to provision the RADIUS client.

  The details have to be worked out, but given that there's similar work being done already, the hope is that the details aren't too complex.

  Alan DeKok.