IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Tue, 29 November 2022 22:42 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 A4CC9C14CEE6 for <radext@ietfa.amsl.com>; Tue, 29 Nov 2022 14:42:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 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, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 3cyducqGZl_3 for <radext@ietfa.amsl.com>; Tue, 29 Nov 2022 14:42:41 -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)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B217C14F727 for <radext@ietf.org>; Tue, 29 Nov 2022 14:42:41 -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 EF3C9319; Tue, 29 Nov 2022 22:42:36 +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: <CAA7Lko_bbpdVnfS6x3k56W0MnfQkfBxGTbVrViw4Td2J-0H_Nw@mail.gmail.com>
Date: Tue, 29 Nov 2022 17:42:35 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9A56812C-E840-4DF6-9D28-18EF528E79F2@deployingradius.com>
References: <FD0507D4-2C1D-478A-97E0-ECEEF1A5613B@deployingradius.com> <EAAC2507-5D29-4453-8881-BC8D9D5314D8@deployingradius.com> <CAOW+2dsKg_H9f3zRUnanCpgGO+G=VPyxzWa9hsrCJCpsnoBsxA@mail.gmail.com> <7CB701B8-BD8F-4ADC-9265-12FC7EBE8FB6@deployingradius.com> <CAOW+2dtDkN3Hvk1vmuyJYGP9KS5WaGDenwQBb7-g12e6SxvEzw@mail.gmail.com> <05f4711f-4f9f-7bb6-e04f-b3c9ebc73202@dfn.de> <9e24bb0f-b12b-8235-3e88-65d4c59f205c@newtoncomputing.co.uk> <e94b8273-6189-efc4-dfa5-3ab3bacbdac6@dfn.de> <7cdb23d1-1d91-71ed-14ee-157315beb278@newtoncomputing.co.uk> <7604703a-075f-7ad6-9c85-24e9a0f845fb@dfn.de> <CAA7Lko9wSP0E8tSQwQ4uhud-f+OBZf6Nw-EGf0XqLPkg8vpN8A@mail.gmail.com> <6D8C428B-D837-4FFE-9739-99C7C20FF64D@deployingradius.com> <CAOW+2dvxo0cpg5+1W-Tyo=s3Ee7EGWFnn+GgW6juEous+6+dug@mail.gmail.com> <9388DD9A-7E92-4C52-8ED8-C36B6282820F@deployingradius.com> <CAOW+2dvc7mKbtzXb_SxBQDarTP_=GrOATvi-dui=giN6jn=ffA@mail.gmail.com> <A4EE4471-92C9-4A7A-AD0B-E2C56EFF8249@deployingradius.com> <cc61da67-e756-de20-aafa-e9485ae9ef57@uni-bremen.de> <CAA7Lko_bbpdVnfS6x3k56W0MnfQkfBxGTbVrViw4Td2J-0H_Nw@mail.gmail.com>
To: Heikki Vatiainen <hvn@radiatorsoftware.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/hQVw76P_1Q6qc2Iy5ltXy7fG8IE>
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, 29 Nov 2022 22:42:45 -0000

On Nov 29, 2022, at 1:10 PM, Heikki Vatiainen <hvn@radiatorsoftware.com> wrote:
> Allowing forwarding with RADIUS/TLS has the downside that the flag would 
> be lost and it could result in RADIUS/UDP at some point if it is proxied 
> further.
> Unless we find a way to include the Flag in "plain" RADIUS, but that 
> would also require all proxies to honor the new flag.

  Yes.  The flag could be added as a new attribute.  Which may have utility outside of SRADIUS.

> There's also the possibility that IPsec or some other method is used to securely forward RADIUS/UDP. This may not be easily visible for a Radius proxy. This could lead to a situation that the potential newly added flag is honoured while there's secure transport available.

  I agree.

> Regarding secure transport: The revised Diameter RFC says:
> https://www.rfc-editor.org/rfc/rfc6733.html#section-1.1.3
>    o  Simplified security requirements.  The use of a secured transport
>       for exchanging Diameter messages remains mandatory.  However, TLS/
>       TCP and DTLS/SCTP have become the primary methods of securing
>       Diameter with IPsec as a secondary alternative.  See Section 13
>       for details.  The support for the End-to-End security framework
>       (E2E-Sequence AVP and 'P'-bit in the AVP header) has also been
>       deprecated.
> 
> The obsoleted RFC 3588 defined 'P'-bit as:
>       The 'P' bit indicates the need for encryption for end-to-end security.
> 
> A quick search didn't tell why the above changes were done, but if secure transport flag is considered, it might be useful to see what happened in Diameter's case.

  Hmm... I don't recall following that discussion or why it happened.  But if Diameter doesn't see a need for an end-to-end security flag, then I'm happy to leave it out of RADIUS.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email