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

Alan DeKok <> Sun, 15 October 2023 19:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BA54DC14F75F for <>; Sun, 15 Oct 2023 12:53:44 -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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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 Ikjb7SmK1vVD for <>; Sun, 15 Oct 2023 12:53:41 -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 C6335C14CE3B for <>; Sun, 15 Oct 2023 12:53:39 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTPSA id 8F800308; Sun, 15 Oct 2023 19:53:36 +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: Sun, 15 Oct 2023 15:53:34 -0400
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: Sun, 15 Oct 2023 19:53:44 -0000

On Oct 14, 2023, at 3:35 PM, Heikki Vatiainen <> wrote:
> First, there are two sections where it's stated that 'This section is not normative.'. Does this mean all the other sections are normative or should the normative sections marked as such?

  Perhaps instead "This section is informative, and contains no normative text."

  i.e. when the document gives a short-hand summary of ALPN, it's not re-defining ALPN.

> Second, in section '3.3. Configuration of ALPN for RADIUS/1.1' the draft says:
>    "1.1" - Require the use of RADIUS/1.1
>       Server Behavior -
>         If the server receives no ALPN name from the client, it MUST reply with a TLS alert of "no_application_protocol" (120), and then close the TLS connection.
> The MUST above appears to be wrong because server's ALPN functionality doesn't need to run if there's no ALPN extension. The draft also says a similar thing later:
>    While [RFC7301] does not discuss the possibility of the server sending a TLS alert of "no_application_protocol" (120) when the client does not use ALPN, we believe that this behavior is useful. As such, servers MAY send a a TLS alert of "no_application_protocol" (120) when the client does not use ALPN. ...
> Should the MUST be a MAY?


> Third, section '3.3.2 Tabular Summary' describes the 'Alert' result as follows
>     Alert -
>     The client sends either no ALPN, or the server does not agree to the clients ALPN proposal. The server replies with a TLS alert of "no_application_protocol" (120), and then closes the TLS connection.
>     As noted in the previous section, the server may send a Protocol-Error packet to the client before closing the connection.
> Alert 120 happens only when the ALPN strings have no elements in common. 'Alert' is marked only for the two cases where the both TLS endpoints are using (sending and receiving) ALPN strings.
> My suggestion is to remove 'The client sends either no ALPN, or' and also drop the possibility to send Protocol-Error. If Alert 120 is used, there's no TLS connection and no data, in this case Protocol-Error, can be sent.


> Fourth, the paragraph below in section '3.5. Session Resumption ', is it really needed?
>    In contrast, there is no requirement for a client or server to force the use of [RFC6614] RADIUS/TLS on session resumption. Clients are free to signal support for "radius/1.1" on resumed sessions, even if the original session did not negotiate "radius/1.1". Servers are free to accept this request, and to negotiate the use of "radius/1.1" for such sessions.
> This section forbids bidding down from "radius/1.1" during session resumption. Is it really necessary to allow the opposite? If the configuration changes so that "radius/1.0" is no longer used and "radius/1.1" is used instead, why not simply do a full handshake. Or in general, if ALPN strings change, full TLS handshake must be done. In case there are new ALPN strings defined in the future, this might be a useful forward compatible definition to have from the start.

  I think it's OK to allow negotiation upwards.  This allows implementations to re-used resumption tickets when the configuration changes.  The alternative is to require full handshake, which sees, inefficient.

> Fifth, there's a paragraph in section '6.4 Error-Cause Attribute' that discusses Error-Cause in Access-Reject and its unknown origin.
> This may come from Radius -> Diameter translation. See the second last paragraph in RFC 4005 section 9.1.1:
>    Any attributes included in the COA-Request or Access-Accept message
>    are to be considered mandatory in Diameter.  If they cannot be
>    supported, they MUST result in an error message return to the RADIUS
>    server, with an Error-Cause of "Unsupported Attribute". 
> I'm not sure if this is where Error-Cause in Access-Reject comes from, but it sounded familiar from Diameter. It seems the 'error message' would Access-Reject.

  OK.  I'll reword the text so that it says 5080 doesn't _explain_ why Error-Cause was allowed in Access-Reject.

> Finally, the 'IANA Considerations' section is missing ALPN string 'radius/1.0'. Does it need to be registered?


> There were also a couple of small typos etc. I'll make a Github pull request for those.


> The rules in section '3.2. Operation of ALPN' would benefit from a couple of implementations, especially when Protocol-Error message is used. I'll see about updating my tester.


  The FreeRADIUS implementation still uses "radiusv11 = forbid / allow / require", but it does send the "radius/1.0" string if necessary.

  Alan DeKok.