Re: [radext] BoF request for IETF 115

Alexander Clouter <alex+ietf@coremem.com> Sat, 24 September 2022 06:13 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 80B18C14CE28 for <radext@ietfa.amsl.com>; Fri, 23 Sep 2022 23:13:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.809
X-Spam-Level:
X-Spam-Status: No, score=-2.809 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_LOW=-0.7, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=giMgKr3k; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VBsmAFmf
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 9Vfh0Ka2U67d for <radext@ietfa.amsl.com>; Fri, 23 Sep 2022 23:13:01 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (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 EA463C14F735 for <radext@ietf.org>; Fri, 23 Sep 2022 23:13:00 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B8AD95C00B7 for <radext@ietf.org>; Sat, 24 Sep 2022 02:12:59 -0400 (EDT)
Received: from imap46 ([10.202.2.96]) by compute4.internal (MEProxy); Sat, 24 Sep 2022 02:12:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coremem.com; h= cc:content-transfer-encoding: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=1663999979; x= 1664086379; bh=jFPT3XoT69G/uioRBUzT1PXSFJcuZ9CUmX1KZFQIL08=; b=g iMgKr3ki6kK6k4UceS048jEOZ8Eu1q+d8+d8WYd1VQeh4p49RjHITBhTcAM7yU/l VKnTuS7o1ejPFwm4NG8a7WxAgJ6wZJI7EZnk8By4t28D4QEt9eiGdgoA9AqnGsbj 6FsMea+rOhcIF7/kgCJ7FjOjJfz36vmH35eq9zq72sbh3zOzsKF7oHH+H285SnVY 2eoEPPFhrrwd0bXyJJCVxISk6MgrMrErMTQvlghQmw9wTO45hJWGAV1rw0rVH6MJ DZjt+Pkxvo8HO2zBwPh6aiV8/uhD9AEtu0Tie9seF8/ctcv4a2H6pnSNhXitN5gM T+N2vsG10TC1gxPEPmLwg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=1663999979; x=1664086379; bh=j FPT3XoT69G/uioRBUzT1PXSFJcuZ9CUmX1KZFQIL08=; b=VBsmAFmfwMVSM911r iOGY/m3mlI5GhA86kNd8FHT9ZNlWx8SdnozPuIr3hX/2jNWUex5t04wPcnf7tZRL qSWQ6fXp1iNTpOSzA4cLL/+1wISBMT7xF5LjXw4vLpTbzgik09gFvW328KUlR3cb WnY6JYRK2E6jaeObpdbGlVYHOMyG+/hudkFVuBMjey2Ncn1b+2DF0A0WQaFUK9fG 7F2YUXAoZr8c4ufG59esuRiC/CqBv71LMY1k02OlPuzzYv64nZm4rG5DbD1hg3VA IUdW4+ybhRSn4Nsp407io7WePhf2I3Xl0xGNsjWa1PEcHMpSVdPluPtvEcrZeU8G WMSlw==
X-ME-Sender: <xms:658uY3AvZ0ga8tHNmYrGuhq76G4zmOctnLk6Pivs0gFxCpQtET-5QA> <xme:658uY9juw6urpkt93NojSU5qrSnBdHLX2zV1sRE_zecJlPpzdPBUFOMoXaMk4ID_7 IexweFUamkQKBQkTg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeefjedguddtkecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgse htqhertderreejnecuhfhrohhmpedftehlvgigrghnuggvrhcuvehlohhuthgvrhdfuceo rghlvgigodhivghtfhestghorhgvmhgvmhdrtghomheqnecuggftrfgrthhtvghrnhepgf dtvedthfelgefhleejfffhuedttdfgtedvgeeuffettdduhedtieefvdfgjeeknecuffho mhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpegrlhgvgidoihgvthhfsegtohhrvghmvghmrdgtohhm
X-ME-Proxy: <xmx:658uYykag6GRb8BHCsl9NTB7JbGwg1dwmVBC9QWcwaoTaNiTcDzQeA> <xmx:658uY5xlAn9Ktjoq6OuBPcVmn4-KGpFT7GC_J_6IonwbOQ1su1zsxQ> <xmx:658uY8QvY2tI5WZz6rA5W7oyS28QLH5QTZv-3yi5xwOJOVEkHc4k_w> <xmx:658uYzcYRGPRhjwD7X_dv-MNCamBLEkC_BWH62MeI2sJj5xgz1TDDg>
Feedback-ID: ie3614602:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7E1C32A20079; Sat, 24 Sep 2022 02:12:59 -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: <788eea99-21ab-4cc7-8e3e-67a2f8f480d6@www.fastmail.com>
In-Reply-To: <ab874879-3cdd-6cdb-e9a0-07a405272088@iea-software.com>
References: <CAOW+2ds134ZJ+somFXsL=27=pvtUT2hNU6G9_8cpM3VoWEcN9Q@mail.gmail.com> <ab874879-3cdd-6cdb-e9a0-07a405272088@iea-software.com>
Date: Sat, 24 Sep 2022 07:12:39 +0100
From: Alexander Clouter <alex+ietf@coremem.com>
To: radext@ietf.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/yHS9_03S-vP8An5rafj_Mi9cfEI>
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 06:13:05 -0000

On Fri, 23 Sep 2022, at 21:38, Peter Deacon 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.
>
> Recommend using PAKE like the old TLS-SRP instead of TLS-PSK for password 
> based secrets.

Someone did try to graft PAKE into TLS but it ran out of steam[1]. Should this be a blocker to the SRADIUS draft?

That draft though did lead me to DH-PSK[2] but also Hybrid Public Key Encryption which states the same problem of how to handle low entropy keys[3]. There though the problem is the low cost of doing brute force, which mixing in (somehow with magic) a step similar to PBKDF2 might help buy the user more time to notice an attack and rotate keys.

Trying to make bullet proof an environment where someone wants to use their pets name as a PSK is probably a battle we are going to lose. In fairness, it is also a choice the user made for reasons that make sense to them and their local environment...it may not be correct but I am not sure there is anything anyone can do there.

Cheers

[1] https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
[2] https://datatracker.ietf.org/doc/html/rfc9257#section-4.2
[3] https://datatracker.ietf.org/doc/html/rfc9180#section-9.5