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

Alan DeKok <aland@deployingradius.com> Tue, 22 November 2022 21:29 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 B7C35C14CF12 for <radext@ietfa.amsl.com>; Tue, 22 Nov 2022 13:29:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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] 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 qvOxZa0kPGIK for <radext@ietfa.amsl.com>; Tue, 22 Nov 2022 13:28:59 -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 1DA13C14F735 for <radext@ietf.org>; Tue, 22 Nov 2022 13:28:58 -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 8D410319; Tue, 22 Nov 2022 21:28:55 +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: <329FE6EA-C1E6-4E16-8D0C-A68C32B67FB9@gmail.com>
Date: Tue, 22 Nov 2022 16:28:53 -0500
Cc: Peter Deacon <peterd@iea-software.com>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FC5C81F9-FEB5-4F9C-9A02-36837B7ABC09@deployingradius.com>
References: <4ce6d292-bb34-5dd7-7b8b-d43c282658f1@iea-software.com> <329FE6EA-C1E6-4E16-8D0C-A68C32B67FB9@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/KB_DruXTnIYad5tiy1xoGwMtjYo>
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: Tue, 22 Nov 2022 21:29:00 -0000

On Nov 22, 2022, at 2:06 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> +1 This is how RADIUS over IPsec was deployed to meet FIPS-140 requirements. If a known shared secret is used, and MD5 is turned off for user auth and attribute hidimg then MD5 serves no security purpose. 

  The nit here is that MD5 is still used for packet authentication and attribute hiding with RADIUS/TLS.  It doesn't add any security, but it is still used.

  And in practice "FIPS" means "forbid MD5".  There are exceptions and explanations needed as to why RADIUS is somehow special, and how the FIPS requirements don't apply to RADIUS.  Because... reasons.

  A typical security process follows a checklist, "no MD5" is a checklist.  "Explain why RADIUS is special" is a problem.

  Alan DeKok.