Re: [radext] BoF request for IETF 115

Alan DeKok <> Fri, 30 September 2022 14:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAE25C14CE41 for <>; Fri, 30 Sep 2022 07:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8B0LwKBJJVi for <>; Fri, 30 Sep 2022 07:25:05 -0700 (PDT)
Received: from ( []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 7AFE1C1522B7 for <>; Fri, 30 Sep 2022 07:25:04 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 9F11970B; Fri, 30 Sep 2022 14:24:57 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Alan DeKok <>
In-Reply-To: <092e01d8d4c5$63de52b0$2b9af810$>
Date: Fri, 30 Sep 2022 10:24:56 -0400
Cc: Stefan Winter <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <092e01d8d4c5$63de52b0$2b9af810$>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [radext] BoF request for IETF 115
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Sep 2022 14:25:10 -0000

On Sep 30, 2022, at 8:08 AM, wrote:
> And operating a private CA is much more difficult than PSKs. Moreover,
> credentialing a large NAS estate with client certs could be a lot of effort.
> And, from operator experience, many folks simply don't understand client
> certificates and key management. Conversely, PSKs are intuitive.

  I had conversations this week with an organization running 10K RADIUS servers.  They had a difficult time understanding basic concepts around certificates.

  So yes.  Certs are good, but they are hard.

> RFC7250 assumes out of band key provisioning. Again, I think provisioning
> keypairs on a server and client would stretch most users. With PSK, it is
> the same key on both entities. It is hard to get this wrong.

  I have an eye twitch from 20 years of messages on a mailing list which ask:

	The logs say "shared secret is wrong.  Please double-check it on the NAS
	and in the configuration files"
	What does this mean?

  It is apparently trivial to get PSKs wrong.  It's difficult to get people to read and understand basic log messages.

  It's very, very, difficult to convince people to use complex PSKs.

  I'm writing up some drafts on this, and will publish them in a week or so when they're a little more polished.

> I have no objection to some form of public key based authentication; but we
> need support for PSKs or this will be too hard for most users.

  I agree.

  Alan DeKok.