Re: [radext] Implementation independent ALPN selection for RADIUS versions

Alan DeKok <> Mon, 16 October 2023 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4DC6EC15154A for <>; Mon, 16 Oct 2023 06:16:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 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, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 45UIn8Q7NL4A for <>; Mon, 16 Oct 2023 06:16:51 -0700 (PDT)
Received: from ( []) (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 (Postfix) with ESMTPS id A5325C1705E0 for <>; Mon, 16 Oct 2023 06:16:49 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 300EE308; Mon, 16 Oct 2023 13:16:46 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
From: Alan DeKok <>
In-Reply-To: <>
Date: Mon, 16 Oct 2023 09:16:44 -0400
Cc: Heikki Vatiainen <>,
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Alexander Clouter <>
X-Mailer: Apple Mail (2.3696.
Archived-At: <>
Subject: Re: [radext] Implementation independent ALPN selection for RADIUS versions
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Oct 2023 13:16:55 -0000

On Oct 16, 2023, at 4:03 AM, Alexander Clouter <> wrote:
> I would not be concerned about any inefficiency of a full handshake, I suspect this is going to be really rare and only occur if either peer is upgraded (or configured) to start supporting 'radius/X.Y' which is going to be a rare event?

  I suspect this will be generally rare, but perhaps useful as part of an upgrade process.

> My concern would be if there is some sort of authentication or authorisation that an implementator/administrative may want to tie back to the original full handshake via those interim session tickets that may vary given a different ALPN negotiation?

  Authorization should either be tied to the session ticket, or re-done completely.  The issues are similar to EAP-TLS:

> If we can think of a single scenario, even a crazy one, we should forbid negotiation upwards too.

  I agree.

> I cannot think of anything as this is 'transport' rather than 'peer authentication', so I'm okay with session tickets going upwards.
> That said, implementation wise, I suspect most peer session tickets are going to be memory resident, so upgrading your RADIUS peer or reconfiguring and reloading may just nuke those tickets anyway so this might be all moot :)

  In high-load / load-balancing environments, I suspect that it will be important to put session tickets into a database.  That way the RADIUS servers can be "bounced" or upgraded without forcing hundreds of clients to do a full re-authentication.

  Alan DeKok.