IETF Logo Mail Archive

[radext] Re: Lack of Channel Bindings in RADIUS/(D)TLS

Alan DeKok <aland@deployingradius.com> Tue, 30 July 2024 14:28 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 B28ABC14F71B for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 07:28:58 -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 8Mdlh6Qn0UTd for <radext@ietfa.amsl.com>; Tue, 30 Jul 2024 07:28:57 -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 ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624A3C14F6EC for <radext@ietf.org>; Tue, 30 Jul 2024 07:28:57 -0700 (PDT)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id 5FB91540; Tue, 30 Jul 2024 14:28:54 +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: <FEFA81DA-BE18-4B29-B214-2D05E6DFD933@gmail.com>
Date: Tue, 30 Jul 2024 10:28:53 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <27CE2C75-C758-4091-A68D-B71DC6392FD1@deployingradius.com>
References: <CAOW+2dv7ZXMtoEDunM+x7PgT32-KuXt+1kPeB5giGzewFvotng@mail.gmail.com> <FEFA81DA-BE18-4B29-B214-2D05E6DFD933@gmail.com>
To: Margaret Cullen <mrcullen42@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Message-ID-Hash: GPXZDPIRV54EOS7RWHSJJMZP5QCT6XPB
X-Message-ID-Hash: GPXZDPIRV54EOS7RWHSJJMZP5QCT6XPB
X-MailFrom: aland@deployingradius.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-radext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Bernard Aboba <bernard.aboba@gmail.com>, Fabian Mauchle <fabian.mauchle=40switch.ch@dmarc.ietf.org>, radext@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [radext] Re: Lack of Channel Bindings in RADIUS/(D)TLS
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/4tzzCW6lKAHBeNDqeGXcS1oOnVs>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Owner: <mailto:radext-owner@ietf.org>
List-Post: <mailto:radext@ietf.org>
List-Subscribe: <mailto:radext-join@ietf.org>
List-Unsubscribe: <mailto:radext-leave@ietf.org>

On Jul 26, 2024, at 10:11 PM, Margaret Cullen <mrcullen42@gmail.com> wrote:
> I would say that we _do_ need to take a position on whether TLS 1.2 provides sufficient security for RADIUS, whether we  say this in the RADIUS/(D)TLS security considerations or not.

  I believe TLS 1.2 provides sufficient security.  I would also be OK with mandating TLS 1.3 support for all clients and servers.

  RFC 8446 is 6 years old.  There is zero reason to make TLS 1.3 optional.  Plus, the BlastRADIUS vulnerability highlights the problem with using old crypto.

  The historical approach has been "we don't want the standards to mandate better security, because that would (a) require us to change our implementations, and (b) highlight the fact that our products are imperfect".

  I think the approach in 2024 should instead be "the standards will mandate the best possible security, and leave it to vendors to explain why they don't use it".

  Alan DeKok.

v2.35.0 | Report a Bug | By Email | System Status