IETF Logo Mail Archive

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

Bernard Aboba <bernard.aboba@gmail.com> Wed, 23 November 2022 16:13 UTC

Return-Path: <bernard.aboba@gmail.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 C299EC14F6EB for <radext@ietfa.amsl.com>; Wed, 23 Nov 2022 08:13:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 SBdMZHlaiEoG for <radext@ietfa.amsl.com>; Wed, 23 Nov 2022 08:13:55 -0800 (PST)
Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 EC6B3C14F731 for <radext@ietf.org>; Wed, 23 Nov 2022 08:13:55 -0800 (PST)
Received: by mail-ed1-x534.google.com with SMTP id s12so25501154edd.5 for <radext@ietf.org>; Wed, 23 Nov 2022 08:13:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=N6KYiX613nDt2CQBCdjgssS8ASlbkOQp13JjYIVwUww=; b=AylXcrk/zRv00ezuWIymclPW4lmJLEnBqEz62b58n/FZM6MEZAnhYNgCnKQFTxnJ+V KyIio+QUMjLQ3rrteicKYIJJvdOc6ntcpPAp75cMHSEE9iPgyGJt2+JlK2Bk3Wh6yh33 EJJChjA1YhFKPzjzAT4DsbyMvKVvgG4On0Go42OfKmVHSHtV0SFVTwPdrOCXlbZUQ7Vs Os4huU0fGj88EKHPXdAugNuI4vrhUm3K4xgZpPFf/y3fE7QFBETK1ITD8Y3qURe/DVUu RVRLTcvFF78atHX4U7ohVXrd4E6XaaU0rxI2G6bZnW6oe2v8AwJlH+Cb1551Z7tZfyWz HE3g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=N6KYiX613nDt2CQBCdjgssS8ASlbkOQp13JjYIVwUww=; b=8GI3iKkIUq1PLXDq1oG3ZYfR6avw7mr3++c4XYgK1A4dEcwaaQfkBkLeXc8ff9Urwg 4eUAHHO3y2jOlPHRItgSQvPSAvq9blMaTgylmAo6Zd0q3X3C2hIXiE/FqiJ1x0P+E7V3 8WGOSm8aeSCqHllwtG9irJHhVqLf/Y5gEadJ6q5wK9wNbyf0gYjBMQTZjtDB1u3A3itq pP7wBEG/gkrZSVn1TVBS17uGxuY8h7JOxYYE7PpFQrswTiVkyYbUgjOjE2Qb/UwG62zS fYoT719Rt9A77LkJKv9/1vlNaLurGSIOdJDB9mG0igZCghE2k8x7rsGSa0IMTxdldXDr i72w==
X-Gm-Message-State: ANoB5pkU9a6j5yao1u3pF0o8RBc/KJUiYvxmXLamYqt9DDdGtyYYw1lg 0tP3kD+Nu/0HwPTofgGGrWOnkfvR6xO8FfXYakaCzwN9Z8Q=
X-Google-Smtp-Source: AA0mqf6AwgiG9IIfDx0k/Cw4V2SvBzfzoIAYkcN84INmPMYXXhqvXrCCICG4p3Uex5BO6giP01lG1TKXbO18l6LYgH0=
X-Received: by 2002:a05:6402:10c3:b0:468:4c9a:7c6c with SMTP id p3-20020a05640210c300b004684c9a7c6cmr25442379edu.397.1669220033343; Wed, 23 Nov 2022 08:13:53 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <b96210fb-8a59-2606-bb0c-7cf365fb23e0@iea-software.com>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Wed, 23 Nov 2022 08:13:42 -0800
Message-ID: <CAOW+2dvoh=i1m=beV8aJkcbCybXPx86WY8QAEm+u87mTEEuCTQ@mail.gmail.com>
To: Peter Deacon <peterd@iea-software.com>
Cc: Jan-Frederik Rieckers <rieckers@dfn.de>, "radext@ietf.org" <radext@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000023b3b905ee259353"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/7dWyKDI_VNfZKms47FI7wCH27tw>
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:57 -0000

On Wed, Nov 23, 2022 at 08:02 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.
>
> 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.
>
> 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.
>
> regards,
> Peter


[BA] +1.  There is no need for two different options, or for deprecating
and replacing existing attributes. That will just create confusion and add
to the already considerable deployment hurdles.

v2.23.0 | Report a Bug | By Email