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

Heikki Vatiainen <> Thu, 27 July 2023 12:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B303C14CE47 for <>; Thu, 27 Jul 2023 05:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tls2JzQVAW6z for <>; Thu, 27 Jul 2023 05:29:44 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id BFDCAC14CE4A for <>; Thu, 27 Jul 2023 05:29:41 -0700 (PDT)
Received: by with SMTP id 4fb4d7f45d1cf-51e28b299adso1200331a12.2 for <>; Thu, 27 Jul 2023 05:29:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1690460979; x=1691065779; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=c4CdBnfzMK+EkTXyHD70v4A0q4frXHeKQwUbpH5yohk=; b=FjQ4maIDyOx/4uTtvexIl4TiKQXsMzCvz+q4DX4OKHpT3Zh3S7C27706qbogul2pVH U4Fk8SG+UD+7KJoD4PBpetyW5GSk3w4IMg1zFzWAwxs0js3sXqK4QXCOlni75TrzgZN6 54FGMVSLwsSDbsR5+FzpgIWMLWmGhH0KU/mg5hk40elfPA4kZviq9knbETu1Qx71cY7y rno3AIrl1p/Rl7iPl8y4TUhhI3qo0++Mbv1G0cjJPPXap1NUwyCXYrdEmn2zppztFneJ /kEYBb9KceoBgUmQCpeaA8flHpmW5+cdcB7QsbdRierKNjQ4vq2zuLJLzUlI7BCtrI3H wjJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20221208; t=1690460979; x=1691065779; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=c4CdBnfzMK+EkTXyHD70v4A0q4frXHeKQwUbpH5yohk=; b=VH0qdDqw4M3YgelLny893DLXqr3n2nbB6hisXxJM0jsd3GgqOd1l5gdQYWVtjPafzA Qz8qCDrXv+10fx4poJsH6m3rGmkBHshB5n1k54yWYJGF66peg+bHw/V+vPk6ZMRNRtV/ KdF2K0c5NGjAkK7htibpVE8GfOPet4lpfA22cOcbuzlVLEnvKNHwzfB+TCbrrWqu9nWu TkiFxkEozAbEgmcBfjpobj7e4BnI/uj9XYQsXH/fyjFCswKqFcbAvXnkAkf6ocJhALdC hVVVYPx6LKXBhycBXGKZBBmNPVN1BzI1+bMqnDXAOR7VBEdw/Mwp7xKDd0vyJcBuA5g6 Gn/Q==
X-Gm-Message-State: ABy/qLaR9aeGu45caicbNtG2k75KcJIq8HBRpkR9NXsZa0B3wZ+DtKu+ r/r2VHdlgmDkpkQ/nqszcq2z4BlW9BOTRYRVlRoCdLCQeZuYmugGWyU=
X-Google-Smtp-Source: APBJJlGtaVexquz7gBbiqLxOAc6uoW9mPHjrkiodlnBY/NVn9X+uwEusQhrYi7M54BWlBtijJCo02HhztyIk4jRVYWo=
X-Received: by 2002:aa7:d3c1:0:b0:522:2a94:1ea4 with SMTP id o1-20020aa7d3c1000000b005222a941ea4mr1638891edr.2.1690460979559; Thu, 27 Jul 2023 05:29:39 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Heikki Vatiainen <>
Date: Thu, 27 Jul 2023 15:29:23 +0300
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000319aae0601771e31"
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: Thu, 27 Jul 2023 12:29:48 -0000

On Wed, 26 Jul 2023 at 23:21, Alan DeKok <> wrote:

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

Preference order and automatic selection are documented here:

If one doesn't use their own ALPN select function, SSL_select_next_proto()
is available and does this:

    The first item in the server, server_len list that matches an item in
the client,
    client_len list is selected, and returned in out, outlen ...

The Go TLS package, as another example, documents similar preference based
selection. ALPN is mentioned a couple of times on the page and the
selection functionality seems to be built-in.

  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.

Explicit instructions are fine. With 'radius/1.0' ALPN string I think we
can do this:
1) Have explicit instructions on how to select a RADIUS version
2) Allow RFC [1] compliant ALPN implementation in the chosen TLS stack to
do the most of the work
3) Avoid saying that we use ALPN and then describe something that's not
quite what ALPN does

- use preference order on the TLS server side
- return alert 120 if there's no overlap on ALPN protocols the TLS
endpoints support

Depending on the TLS stack, useful extra functionality includes triggering
alert 120 when RADIUS/1.1 is required but client doesn't include ALPN
extension in its TLS ClientHello.

Heikki Vatiainen