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

Alan DeKok <aland@deployingradius.com> Mon, 28 November 2022 22:06 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 34E6CC1526E6 for <radext@ietfa.amsl.com>; Mon, 28 Nov 2022 14:06:04 -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 i446iS_go4WU for <radext@ietfa.amsl.com>; Mon, 28 Nov 2022 14:05: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 89F53C1526E3 for <radext@ietf.org>; Mon, 28 Nov 2022 14:05: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 AF7AF6CD; Mon, 28 Nov 2022 22:05: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: <CAOW+2dvxo0cpg5+1W-Tyo=s3Ee7EGWFnn+GgW6juEous+6+dug@mail.gmail.com>
Date: Mon, 28 Nov 2022 17:05:54 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <9388DD9A-7E92-4C52-8ED8-C36B6282820F@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>
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/TyxZioYE7v3ihB8p_6LA5vbJpS4>
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:06:04 -0000

On Nov 28, 2022, at 4:52 PM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
> "  ALPN is about negotiating which application protocol is inside of TLS....   i.e. a hop-by-hop RADIUS packet (inside of TLS) which says "I have this capability".
> 
> [BA] Since TLS ALPN negotiation will be "hop by hop", there could be scenarios where the SRADIUS ALPN could be negotiated on one hop, but not another.  A RADIUS proxy can do the conversion, but that could yield unexpected results.  

  I'm not sure what conversion is necessary.  SRADIUS is a transport profile which essentially says "don't use MD5 to encrypt User-Password when sending packets from client to server".

  Nothing about the content of the User-Password attribute is changed.  It can be sent in another packet (SRADIUS or not) without any issue.

  When a RADIUS proxy receives User-Password, it has to decrypt it, and then store it in memory as raw text.  When that attribute is sent over the next hop, it is (a) encrypted if RADIUS, or (b) not encrypted if SRADIUS.

> For example, say a company requires that new NAS devices support SRADIUS, and upgrades the proxy to support SRADIUS.  But because there are still some legacy devices left, they still have to maintain a legacy RADIUS server in addition to an SRADIUS server.  

  Quite likely, yes.  Or, just allow the RADIUS server to negotiate protocols on a per-connection basis.

  The main purpose of "SRADIUS only" is for people who want to do hard-core FIPS, and remove all references to MD5.

> Is there a way for the company to make sure that SRADIUS NAS devices communicate using SRADIUS on each hop?  Or could an SRADIUS NAS Access-Request end up being routed to a legacy RADIUS server (or a legacy RADIUS over (D)TLS server)? If the proxy negotiates SRADIUS with the NAS, but legacy RADIUS or RADIUS over (D)TLS with the server, then even new devices supporting SRADIUS might not end up talking SRADIUS end-to-end. 

  There's no "end to end" SRADIUS.  It's all hop-by-hop.

  i.e. The SRADIUS draft proposes changes to the packet encoding (MD5 signature, encryption of some attributes).   The content and meaning of the attributes hasn't changed.

  As a hop-by-hop encoding, it's compatible with all RADIUS attributes: past, present, and future.  Once attributes are received by one hop, all previous transport limitations are lost.  Any "next hop" transport operates entirely independently of any previous transport.

  Alan DeKok.