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

Alan DeKok <> Wed, 11 October 2023 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A01B1C151522 for <>; Wed, 11 Oct 2023 11:04:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 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, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id p9nxHUlpeEI5 for <>; Wed, 11 Oct 2023 11:04:45 -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 3F20BC14CE55 for <>; Wed, 11 Oct 2023 11:04:44 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTPSA id 969455B7 for <>; Wed, 11 Oct 2023 18:04:41 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none)
From: Alan DeKok <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.\))
Date: Wed, 11 Oct 2023 14:04:40 -0400
References: <>
In-Reply-To: <>
Message-Id: <>
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: Wed, 11 Oct 2023 18:04:47 -0000

 Revisiting this before the next meeting.

On Jul 26, 2023, at 2:54 PM, Heikki Vatiainen <> wrote:
> Here's a suggestion of how to use ALPN in a way that lets the TLS stack's ALPN implementation to do the most of the protocol selection work. I think draft-ietf-radext-radiusv11-01 can be shortened by describing in detail only what's needed when the both endpoints do not use ALPN. When they do, the TLS stacks' ALPN implementations should already automatically do the right thing.

 I'm OK with leaving some additional explanation in.  But it should be clearly marked as explanatory, and not normative.

> What's described in this message should also be compatible with different TLS implementations. It only requires two things from the both TLS endpoints. I think this is the minimum that is needed in order to use ALPN at all:
> 1. A method to set supported ALPN protocols before a TLS handshake
> 2. When a TLS handshake completes successfully, a method to query if ALPN chose a protocol and if yes, which protocol it chose

 Sure, I'll update the draft to describe that.

> The table below, also attached as a screenshot, uses '1.0' and '1.1' for a shorthand for 'radius/1.0' and 'radius/1.1', respectively. This brings back the 'radius/1.0' protocol string that was is not seen as required by selection logic, which is true, but it's helpful when used as ALPN input. With 'radius/1.0' extra work by RADIUS/1.1 implementation is only needed when RADIUS/1.1 is required and the other end does not support ALPN. In this case the TLS handshake completes successfully, but an API call to find out the selected ALPN protocol returns NULL, or whatever is used to indicate that ALPN negotiation did not happen. When this happens, Protocol-Error or some other action is needed to shutdown the TLS connection.

 I've put a simplified version of the table into the document.

> One additional benefit of 'radius/1.0' ALPN protocol is that it allows the client to make it unambiguous whether it supports ALPN at all. Currently the client must advertise 'radius/1.1' or leave out the ALPN extension completely. This does not:
> a) Allow the client administrator to signal that the client is ALPN capable but has RADIUS/1.1 currently turned off
> b) Allow the server to easily use TLS alert 120 to refuse an incoming TLS connection
> Case a) might be useful when initially setting up ALPN capable TLS client. It may also be useful in a case where there's an implementation bug or some other reason to turn off RADIUS/1.1 for the moment.
> Case b) is the one where the server TLS implementation does not support inspecting ClientHello and triggering TLS alert when ALPN is required (but not present in the ClientHello).

 I've added text describing that,

> I also have the feeling that using ALPN protocol strings for all known versions makes it easier to support RADIUS/1.2, should that be needed.

 Very true.

 Alan DeKok.