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

Alan DeKok <> Wed, 26 July 2023 20:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 85FA5C1522D9 for <>; Wed, 26 Jul 2023 13:21:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 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, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dJqJYaBGCutd for <>; Wed, 26 Jul 2023 13:21:13 -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)) (No client certificate requested) by (Postfix) with ESMTPS id 14BD0C151B0D for <>; Wed, 26 Jul 2023 13:21:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 59F134F3; Wed, 26 Jul 2023 20:21:10 +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: Wed, 26 Jul 2023 13:21:08 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Heikki Vatiainen <>
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, 26 Jul 2023 20:21:17 -0000

On Jul 26, 2023, at 11:54 AM, 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 hope so.  The OpenSSL documentation suggests that the server provide a list of protocols, but it makes no mention of preference order, or automatic selection.

  So it might work, but...

  I think it's worth discussing this possibility, but I'm OK with having more explicit instructions in the draft, too.

> 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).

  That's true.  I'm OK with adding that ALPN string back in, along with the discussion you give here of why it's useful.

> 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.

  Sure.  It never hurts to be forward thinking.

  Alan DeKok.