[radext] Implementation independent ALPN selection for RADIUS versions

Heikki Vatiainen <hvn@radiatorsoftware.com> Wed, 26 July 2023 18:55 UTC

Return-Path: <hvn@radiatorsoftware.com>
X-Original-To: radext@ietfa.amsl.com
Delivered-To: radext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F98DC15107B for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 11:55:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=radiatorsoftware-com.20221208.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhEj13-QvyCu for <radext@ietfa.amsl.com>; Wed, 26 Jul 2023 11:55:10 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 3E433C1522D3 for <radext@ietf.org>; Wed, 26 Jul 2023 11:55:10 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-51e619bcbf9so106583a12.3 for <radext@ietf.org>; Wed, 26 Jul 2023 11:55:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20221208.gappssmtp.com; s=20221208; t=1690397708; x=1691002508; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=JXDBp7prsWAjWtrAlHD0WtMKuiCg/RGcm4ouwDXIFzA=; b=caP4mWaS1bvxOOJgSe1HXExEW4eUBcvJYkkp7em+ZQf+U0tS2MqT8clARrYoq7Ilj0 HsDjbyhF/EvHBgJhDAEP6Bz8PO4aeLsrG/DRYyjW9b2VbzUMopSW822aj8WCQ7/DpAgs kFXkf/k7tKrIykcH/rWswn3b6GPWx7+3EzVfh/C683tgJV0IXXsTeHJGwP6c1Lk66bMC opWXszVLXlOcyXgoUczPWVPoUL424SaixUZ+iUQCCpNj/eJNPWDiP/wxGYUzQxAKr/S5 JtdzJrnxkwUe+0SwK//JF1e3XAXyxbtw81QZJWKPdlgB5ElOokI2odyCTqvx9jOtHpfq 9Hyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1690397708; x=1691002508; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=JXDBp7prsWAjWtrAlHD0WtMKuiCg/RGcm4ouwDXIFzA=; b=FBif2uwRBiVtuRZTh0FIMGwYB0ibSE9rws6X/7aiJ0hK/3CKffcO3QShdMXf39mOgg 4M10Dsaw6rwVaJ7gHN5hy7FQL3/bC3eRy5bBxjNKuSiVeNMLewYKzkxvkHGJ39cmKHm7 OurDa9y/JMnTBZTifWRY7HAM6K7b+NZqXhKG1w/kkD8ju+XpgEZr62Uw6Ex/Da1gfbSI Ng/tY0wLtr29b50c2ZZvfvZXKaAoqJEDlChK7B+HlkOd0XYFPOx+YCY2LYeuUpIeGKmy lX404tskI8+oaTQquBt90wH91rm7VGpB03XWuDKNYO1lp3UUISCWxMFZ7bukHZ5fPMxA D9IA==
X-Gm-Message-State: ABy/qLaBZ1+SLlFKMZmRnsMgwS8FB4shL40rzUujAsG3ldedCyOuycM5 o97MmGIlBJfmGRzUp36gpIHfz4atvxC7Sw5mClz7ZAmA/OXH2RUERtA=
X-Google-Smtp-Source: APBJJlEvP+Hoi+81tvSvczfEKwzZr1w2p++OGlORj34Z8C97XoB/UX9b1LHG7TEq5ud23LKbFiA1pM32o4sQSTeA+oY=
X-Received: by 2002:aa7:c0cf:0:b0:51e:2305:931 with SMTP id j15-20020aa7c0cf000000b0051e23050931mr30826edp.22.1690397707824; Wed, 26 Jul 2023 11:55:07 -0700 (PDT)
MIME-Version: 1.0
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Wed, 26 Jul 2023 21:54:51 +0300
Message-ID: <CAA7Lko-dC3R=QdUJOwXycDJ=LxkQatx0ZrTf7Q21f22zbYdR0A@mail.gmail.com>
To: radext@ietf.org
Content-Type: multipart/mixed; boundary="000000000000e7a2c6060168622a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/qYdhcppeaqfa6U2jfb047IQi_TU>
Subject: [radext] Implementation independent ALPN selection for RADIUS versions
X-BeenThere: radext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <radext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/radext>, <mailto:radext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/radext/>
List-Post: <mailto:radext@ietf.org>
List-Help: <mailto:radext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/radext>, <mailto:radext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jul 2023 18:55:12 -0000

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.

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

Specifically, no custom callbacks for ClientHello inspection or ALPN
selection are required. The TLS stacks ALPN implementation needs to simply
do what the ALPN RFC says
https://www.rfc-editor.org/rfc/rfc7301.html#section-3.2

   ... the server SHOULD select the most
   highly preferred protocol that it supports and that is also
   advertised by the client.  In the event that the server supports no
   protocols that the client advertises, then the server SHALL respond
   with a fatal "no_application_protocol" alert.

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.

The table summarises what TLS stack's ALPN implementation can automatically
do when the both TLS endpoints support ALPN and what remains for the
RADIUS/1.1 implementation to handle. The bottom row and the rightmost
column are what's not done automatically by ALPN. These are the cases that
RADIUS/1.1 implementation needs to handle.

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

Here's the table I've mentioned above. I've also attached it as a
screenshot because it likely gets broken inline.

Server ALPN settings
1.1 1.1, 1.0 1.0 No ALPN
1.1 ALPN 1.1 ALPN 1.1 TLS alert 120 Client closes
Client ALPN settings 1.1, 1.0 ALPN 1.1 ALPN 1.1 ALPN 1.0 Implicit 1.0
1.0 TLS alert 120 ALPN 1.0 ALPN 1.0 Implicit 1.0
No ALPN Server closes Implicit 1.0 Implicit 1.0 Implicit 1.0
Implicit 1.0

RADIUS/1.0 is chosen because one TLS endpoint did not use the ALPN
extension and the other allows RADIUS/1.0
Client closes

The client requires RADIUS version 1.1 or later and the server did not use
the ALPN extension.
The client closes the TLS connection and sends a Protocol-Error. The client
logs the problem.
Server closes

The server requires RADIUS version 1.1 or later and the client did not use
the ALPN extension.
The server responds with TLS alert 120, if possible, or sends a
Protocol-Error, and closes the connection. The server logs the problem.

-- 
Heikki Vatiainen
hvn@radiatorsoftware.com