Re: [radext] BoF request for IETF 115

Alexander Clouter <alex+ietf@coremem.com> Sat, 24 September 2022 05:43 UTC

Return-Path: <alex+ietf@coremem.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C292C14F74B for <radext@ietfa.amsl.com>; Fri, 23 Sep 2022 22:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.108
X-Spam-Level:
X-Spam-Status: No, score=-7.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=coremem.com header.b=NZHB/K7J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=aPf8QTp5
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPusCon--aX8 for <radext@ietfa.amsl.com>; Fri, 23 Sep 2022 22:43:44 -0700 (PDT)
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 5BF92C14F736 for <radext@ietf.org>; Fri, 23 Sep 2022 22:43:44 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 3B34A3200645 for <radext@ietf.org>; Sat, 24 Sep 2022 01:43:43 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute4.internal (MEProxy); Sat, 24 Sep 2022 01:43:43 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1663998222; x=1664084622; bh=KMwyqlCXfL /gjyFhVwfSsQY/m35SuPXlJVqSJD2BEGY=; b=NZHB/K7J5Gj7ljmXgfnsR37RVQ H3D9V9KQ/r1/s+aKEh1P8RGXi6eEknlX6auCpsg7noNSkN6dxiYfmq89iE0jwM8w pa2QyPKEgVTZs/Oc/Bc7sptONQS93VJU5xR+bQhiQGJTChEacCvMqsYd2Tjr2CJ/ Oj0HP5Ddv1I8+dVFRNOIX/0CrlxjGq7Y0PsN5cD4juiHsLVc9oXO4LlRaZBmnBok 8PHWHMDJV0SRNWceWuuBMWqE7WUHVguZrLCbJV6T+rstAATV7VptuYcp3nQYn81u 31HDo1V1OVR5zVa/Bg1FMmSbf45JAqmXB/7P2zrmujgJY0LpiDwRdlKAkMXA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1663998222; x=1664084622; bh=KMwyqlCXfL/gjyFhVwfSsQY/m35S uPXlJVqSJD2BEGY=; b=aPf8QTp5/NlgEtzThTGvhTRZbxK3NAT6y7NHel4y5ftb 51Sp6AmNpjQuxfktpPpk8h69UrIx8sLbmzDhXSESzRk3PWicCQYWazxgqDLwa+d+ jX4ODtVfOjB3c3ywy0eLEvjmm+D52/0vhHX9Z89ir6YXMMzaiOCA+w+IXAIHhQh3 d5eFoveJj+8raHtM/XjrUR1PqRJwvn6XYtXHMw8pK+9EtF/sx4oJN+tK6+gWwj5D f2z/U/PiCSj3rGuCJ46ARDbGHYT/sRMAOfQXanQy7DnBVXBSV1LuRuYkRI/XYuJX hXwtfsHqO3sGZZ+F1jArzbt0C6DH/N95xEVBZRuvxA==
X-ME-Sender: <xms:DpkuYzRmzQGrkK1nbaKHgeuOQaYTwAzvQq9v9zTQ_mv-vPHM2oOgrg> <xme:DpkuY0xYLebWFW9oYyTcxkJ_cAfwrlVdLPFvsGbIvXh8orOXu1Z8dc6XqnsXOqnaJ ikxENzvRe39xj-tEw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefjedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdetlhgvgigrnhguvghrucevlhhouhhtvghrfdcuoegr lhgvgidoihgvthhfsegtohhrvghmvghmrdgtohhmqeenucggtffrrghtthgvrhhnpeetud fhhffgtdegfedtjeelffefkefhjeehudeitdetgfeuleffheduveefuefhjeenucffohhm rghinhepuhhsvghnihigrdhorhhgpdhrfhgtqdgvughithhorhdrohhrghenucevlhhush htvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhgvgidoihgvthhf segtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:DpkuY404EwSXankPn4wQ3OGAj_O_p9vs12D0lwHtwx5LU6EGevCvnA> <xmx:DpkuYzAu3a2eyrvOcpch37aPjjlRFB0Ib5sThSd-FtR8xfhIl9jS-A> <xmx:DpkuY8iOLy9BUCzujd3xhSzcYX0oPsJkQOQWcVU_EenSYlCzeB1OBQ> <xmx:DpkuY3vjyGsmc5dfxs23RYRWzmkz-I5gGcpWkVVmFN1LcdlmaXLQ8A>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7FF482A20079; Sat, 24 Sep 2022 01:43:42 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-935-ge4ccd4c47b-fm-20220914.001-ge4ccd4c4
Mime-Version: 1.0
Message-Id: <ab0d9880-b2bc-4a64-b3d5-0a33f395d809@www.fastmail.com>
In-Reply-To: <D124631A-DDB7-426F-82E8-F897204C469D@deployingradius.com>
References: <CAOW+2ds134ZJ+somFXsL=27=pvtUT2hNU6G9_8cpM3VoWEcN9Q@mail.gmail.com> <D124631A-DDB7-426F-82E8-F897204C469D@deployingradius.com>
Date: Sat, 24 Sep 2022 06:43:22 +0100
From: "Alexander Clouter" <alex+ietf@coremem.com>
To: radext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/K-yBSwmZSnNHkZsCvtOYSeQZLi8>
Subject: Re: [radext] BoF request for IETF 115
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Sep 2022 05:43:49 -0000

On Fri, 23 Sep 2022, at 22:18, Alan DeKok wrote:
> On Sep 23, 2022, at 3:58 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>> 
>> My concern is that the "shared secrets" used in today's RADIUS deployments often have little entropy, leaving them open to password-guessing attacks.  So some additional thinking may be required here. 
>
> I agree.  Some guidance here would be useful.  If we're depending on 
> TLS-PSK for security, there isn't much point in having the PSK have low 
> entropy.

I think we can take some basic steps to juice that up though given the environment; one in which the user is providing low entropy secrets thus firmly lies on the 'not Mossad'[1] side of the security threat model:

1. introduce a user supplied organisation/site shared secret to provide us with a salt
2. use PRF/HKDF to extract as much substance as you can from a weak user supplied PSK and salt
3. make calculating that output more expensive by then pushing that output through PBKDF2 or equivalent

I did just pull this strategy out of thin air and folks can poke holes in this (in particular the setting into stone "use PBKDF2") but the aim here is to provide a parallel to shared secrets from traditional RADIUS into the secure RADIUS world. That is going to be flawed because of legacy, all we could do is provide stepping stones to a better place for the user to end up.

Another option is that TLS supports post-handshake authentications[2], but you are already doing a public key authentication at that point either in effect using anon[3] or self-signed certs which the user would have to pin just so the server side knows what to trust.

On the topic of certs, I think harder is what is going to be validated in the SAN/subject? The NAS's IP (which it may have many)? A hostname (dynamic IP where DNS lags reality)? I think this is the harder problem here, though hopefully I am missing something obvious.

Cheers

[1] https://www.usenix.org/system/files/1401_08-12_mickens.pdf
[2] https://www.rfc-editor.org/rfc/rfc8446#section-4.6.2
[3] https://www.rfc-editor.org/rfc/rfc8446#appendix-C.5