Re: [radext] BoF request for IETF 115

[Alan DeKok <[e-mail]>]

On Sep 24, 2022, at 9:33 AM, <[e-mail]> <[e-mail]> wrote:
> Is there any mileage in requiring implementations to only accept PSKs that
> have defined characteristics that ought improve entropy (e.g. >N octets
> representing some mix of upper/lower/number/special characters)?

  I think it's hard to have a reasonable estimate for entropy.  The simplest thing would be to require that PSKs are at least N characters long.

> RFC2865 is already halfway there:
> 
>      The secret (password shared between the client and the RADIUS
>      server) SHOULD be at least as large and unguessable as a well-
>      chosen password.  It is preferred that the secret be at least 16
>      octets.  This is to ensure a sufficiently large range for the
>      secret to provide protection against exhaustive search attacks.
>      The secret MUST NOT be empty (length 0) since this would allow
>      packets to be trivially forged.
> 
> Taking this a step further, we could require servers to generate high
> entropy PSKs for their clients. The administrator configures the PSK (e.g.,
> copy and paste) into the client OOB. I used this approach for the UK's
> eduroam implementation (RFC2865 secrets), and users managed fine.

   Here's my $0.02, save it as a file "getsecret"

#!/usr/bin/env perl
use strict;
use warnings;
use MIME::Base32;
use MIME::Base64;
use Crypt::URandom();

print join('-', unpack("(A4)*", lc encode_base32(Crypt::URandom::urandom(12)))), "\n";
# end Perl

$ ./getsecret
nwas-3mnm-wo3t-t7pn-abuq

  That returns 96 bits of randomness, printed in a form which is easily understandable.

  Alan DeKok.