IETF Logo Mail Archive

Re: [radext] New draft: RFC6614bis (RADIUS/TLS)

Alan DeKok <aland@deployingradius.com> Sat, 29 October 2022 12:15 UTC

Return-Path: <aland@deployingradius.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 8B66AC14CF03 for <radext@ietfa.amsl.com>; Sat, 29 Oct 2022 05:15:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tnJNq9YlpWZh for <radext@ietfa.amsl.com>; Sat, 29 Oct 2022 05:15:50 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D79C14F722 for <radext@ietf.org>; Sat, 29 Oct 2022 05:15:49 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id CA58AF8; Sat, 29 Oct 2022 12:15:47 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CAOW+2dsSEvv5Zr9ss1v4vpPbuQHbjhbe3iZ=TXRTkgR0hJU62Q@mail.gmail.com>
Date: Sat, 29 Oct 2022 08:15:46 -0400
Cc: Jan-Frederik Rieckers <rieckers@dfn.de>, Peter Deacon <peterd@iea-software.com>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AA00F8E-66B3-4B52-80A8-D5C939D6B19B@deployingradius.com>
References: <d9a015f8-60a7-8eb1-65e0-ea19633c3784@dfn.de> <ef1855a1-2417-b3b0-ba4d-729bc507f151@iea-software.com> <5ac1c43d-9638-9d68-6e8f-d0f2c1137bd3@dfn.de> <B3C2A71B-0796-4B74-8016-99A8341C18F8@deployingradius.com> <CAOW+2dsac4CrafjUZLiu1UhFSArY5gV7t_uVyMwhGn19zJihKA@mail.gmail.com> <973BEA8E-45AE-403F-8CD9-F06D7289E4FB@deployingradius.com> <CAOW+2dsSEvv5Zr9ss1v4vpPbuQHbjhbe3iZ=TXRTkgR0hJU62Q@mail.gmail.com>
To: Bernard Aboba <bernard.aboba@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/UIdquxYP8cRoLH5KvdTt-ER9vx4>
Subject: Re: [radext] New draft: RFC6614bis (RADIUS/TLS)
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, 29 Oct 2022 12:15:52 -0000

On Oct 28, 2022, at 12:34 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> [BA]  The problem would still raise its head again when TLS 1.4 comes out. 

  Yes, true.

> One way to not force operators to configuration multiple PSKs would be to hash a configured "RADIUS over (D)TLS" PSK with the TLS version number to produce a PSK unique for each TLS version number.

  That may work.  I'm not familiar enough with the TLS state machine to say if the PSK identity / value is checked before version negotiation is complete.

  I'm also a little wary of defining some kind of "ad hoc" hashing around the PSK.  I'd much prefer to push that kind of work onto OpenSSL.

  If this issue is too hard, I'd just add a note saying "make sure that the PSKs are large and derived from a secure source".  After that... if the underlying cryptographic protocols have issues, well... we can't fix them in RADEXT.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email