IETF Logo Mail Archive

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

Alan DeKok <aland@deployingradius.com> Mon, 28 November 2022 22:19 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 CCE83C1526E8 for <radext@ietfa.amsl.com>; Mon, 28 Nov 2022 14:19:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 h0VDzuOVod4T for <radext@ietfa.amsl.com>; Mon, 28 Nov 2022 14:19:12 -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 4E25CC1526E5 for <radext@ietf.org>; Mon, 28 Nov 2022 14:19:11 -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 D52BA6CD; Mon, 28 Nov 2022 22:19:09 +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: <CAOW+2dvc7mKbtzXb_SxBQDarTP_=GrOATvi-dui=giN6jn=ffA@mail.gmail.com>
Date: Mon, 28 Nov 2022 17:19:08 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <A4EE4471-92C9-4A7A-AD0B-E2C56EFF8249@deployingradius.com>
References: <FD0507D4-2C1D-478A-97E0-ECEEF1A5613B@deployingradius.com> <E82B0ECD-4580-4F35-B07B-35685CFC5C44@aiven.io> <883f3572-121f-5ed8-7378-1a91c5525f88@iea-software.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>
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/3uhSfO6wwDtUoGJO2KPtfX4dI_k>
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: Mon, 28 Nov 2022 22:19:13 -0000

On Nov 28, 2022, at 5:15 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> [BA]  The question is whether the meaning is "when sending packets from client to server" (e.g. E2E conformance) or "when sending packets on this hop".  That is, can a proxy receive an SRADIUS packet from a NAS and then speak RADIUS (or legacy RADIUS over (D)TLS) to the server?

  Yes.

>  Or does receiving an SRADIUS packet imply that the next hop MUST speak SRADIUS? 

  No.

> A similar issue came up with respect to meaning of the "SIPS" URL.  It turned out that there was no easy way to ensure that security services were uniformly provided on each hop.  Seems like the same might be true here. 

  Yes.

  Stefan pointed out that we should probably add a flag saying "require secure transport".

  i.e. SRADIUS has 8 octets of unused data in the packet header.  It would be good to define one as a flags field: "require secure transport".

  Then if a proxy receives SRADIUS packets with that flag set, it will refuse to proxy the packets over plain UDP / TCP.  RADIUS/TLS is fine, as TLS will take care of securing the data.

  Alan DeKok.

v2.23.0 | Report a Bug | By Email