IETF Logo Mail Archive

Re: [radext] Proposed charter text based on IETF-115 BoF

Alan DeKok <aland@deployingradius.com> Wed, 23 November 2022 16:13 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 32464C14F731 for <radext@ietfa.amsl.com>; Wed, 23 Nov 2022 08:13:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 KwVtqyPren4E for <radext@ietfa.amsl.com>; Wed, 23 Nov 2022 08:13:48 -0800 (PST)
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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADAA2C14F6EB for <radext@ietf.org>; Wed, 23 Nov 2022 08:13:48 -0800 (PST)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 09616257; Wed, 23 Nov 2022 16:13:43 +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: <b96210fb-8a59-2606-bb0c-7cf365fb23e0@iea-software.com>
Date: Wed, 23 Nov 2022 11:13:42 -0500
Cc: Jan-Frederik Rieckers <rieckers@dfn.de>, "radext@ietf.org" <radext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <81A7763B-B2AE-4FBE-9A5E-1234C87393AE@deployingradius.com>
References: <4ce6d292-bb34-5dd7-7b8b-d43c282658f1@iea-software.com> <329FE6EA-C1E6-4E16-8D0C-A68C32B67FB9@gmail.com> <FC5C81F9-FEB5-4F9C-9A02-36837B7ABC09@deployingradius.com> <CAOW+2dtANzJDbAjmhHiz_m1pkk+SyfHu5uZ_ddp4PPMi17=0-A@mail.gmail.com> <E59F655C-ADC3-465A-BC9E-4445135BFE97@deployingradius.com> <2f8a0921-2e9e-751e-4f5d-42c5c9c3cb8a@dfn.de> <b96210fb-8a59-2606-bb0c-7cf365fb23e0@iea-software.com>
To: Peter Deacon <peterd@iea-software.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/1FlNt3zjxW6p6MURd4dmrQW6JLU>
Subject: Re: [radext] Proposed charter text based on IETF-115 BoF
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: Wed, 23 Nov 2022 16:13:50 -0000

On Nov 23, 2022, at 11:02 AM, Peter Deacon <peterd@iea-software.com> wrote:
> Setting shared secret to "radsec" is an unambiguous declaration security of all secret dependencies (PAP, tunnel passwords, MPPE, message-sig/authenticators) are a nullity.  They persist entirely for compatibility and are made redundant by TLS.

  That's true.

> If there is no actual technical requirement I believe it would be better to resolve outstanding confusion with additional text in standards track RADIUS TLS than having two incompatible standards.

  I wouldn't describe them as "incompatible", so much as "different".  RADIUS/TLS is "incompatible" with RADIUS/UDP.  Which doesn't really mean anything, or cause any problems.

> Personally don't care if RadSec or SRADIUS approach is selected.  I see nothing good coming from two different options that accomplish the same thing.

  RADIUS/TLS already exists, but has issues with FIPS.  Whether or not we agree with the standard, the customer demand is that "FIPS compliance" means "no MD5".

  So the SRADIUS proposal is meeting a real-world demand, and the two protocols definitely do not accomplish the same thing.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email