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

Heikki Vatiainen <hvn@radiatorsoftware.com> Sat, 14 October 2023 19:35 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 E701EC1AE9EA for <radext@ietfa.amsl.com>; Sat, 14 Oct 2023 12:35:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=radiatorsoftware-com.20230601.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 KJdSYfhpgd0U for <radext@ietfa.amsl.com>; Sat, 14 Oct 2023 12:35:52 -0700 (PDT)
Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 15226C1AE9DA for <radext@ietf.org>; Sat, 14 Oct 2023 12:35:51 -0700 (PDT)
Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-507a3b8b113so721436e87.0 for <radext@ietf.org>; Sat, 14 Oct 2023 12:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20230601.gappssmtp.com; s=20230601; t=1697312150; x=1697916950; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=2JVGfCkcARoEDGUJtQxkBJ6uSGn+RuWKtiSanURWlxE=; b=U2w3PyP+l1RNnFmPSRlRkByABNNPpmp2hqj9xW+JsdmaWFriSquvikD5FCyf6jZ+Ar THe+X2q6M/+BXYqiTILF/RaYjLg7z3h0LRIlSR44ccW9mZqihCJdoRrF2Ber0bK5qkDj WQq3MVAZC2AQ8fUdjDBDOgdh0NZT+Pm7WZqk2fvkLdyr9YdJyRFAk8+S8eYwtPOzJnB6 VkW4TyLIqI3L+fklUVCkh9zQQeW0XieyXbYzQU7QLr5duH3a0zu0jIjC2WXsFvaWVIbs HaXxuKN4fY1j2roW8fvSYx3eJQqaE8dfjBfbGBqQHaMYRAsmoE2xE3GOue63z1XXuHeI 974w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697312150; x=1697916950; 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=2JVGfCkcARoEDGUJtQxkBJ6uSGn+RuWKtiSanURWlxE=; b=OmzHbpKmoz4I/Sut+I6h6sURhcocIb9cuc6R14D3bOtjPTBUA0MT/R9Tcp+KDoLzAS nQxTJij9tHrOAxF3cKoClD9UFbkSobrtNULz6PapMyygXDF4us0Rb6aH9quCy0mguizc 08GqaZgxemiceEaOTtYiWNpUDEPVwHVfW5/oW8U5ukAi4o8iF57XjkW6/YuWXOkKmkh7 zM/ngb0GcpUyTOR4Ea1Oct2JCjMEZzUj4Mw6vslYQyJM5lRAuI7DL3KN1Yhm06Aqj0WO tuz9ZuMzfM/+ua4cEL98pLCN4tkdM2MNcX9Xzv+JJH3ltrcIIXy9Dp24vw6x7LZ7tcy3 +/Dw==
X-Gm-Message-State: AOJu0YwrnSjPNY8hlThWra1b+3svwT/XYqM+3JaeRYJYk9GvcPLRv01E LiTaTif8TkxeyjFOCMdPYDionZTlpzl2QgjoEdQlQe9LZp2r4dR0TL8=
X-Google-Smtp-Source: AGHT+IHLX0BQfB+Zc7O0fhdKZhaaLm00RkXWJE1+6jwA64GYO0wD2EUvVuML+7FESxa4oSw99U/ekrbJjBsGNvo6Tv0=
X-Received: by 2002:a19:4f09:0:b0:503:3700:7ec3 with SMTP id d9-20020a194f09000000b0050337007ec3mr23643533lfb.39.1697312149812; Sat, 14 Oct 2023 12:35:49 -0700 (PDT)
MIME-Version: 1.0
References: <CAA7Lko-dC3R=QdUJOwXycDJ=LxkQatx0ZrTf7Q21f22zbYdR0A@mail.gmail.com> <5AC9456F-D11A-400F-9DF6-AF458EAC429D@deployingradius.com>
In-Reply-To: <5AC9456F-D11A-400F-9DF6-AF458EAC429D@deployingradius.com>
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Sat, 14 Oct 2023 22:35:33 +0300
Message-ID: <CAA7Lko-7FKAqBx5juqTDvhVdygS_vfDmqkPub8v-M-qmuhUk-g@mail.gmail.com>
To: radext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000c353220607b247bd"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/F5zOlJmDG8XCPFL20gK862QYxBU>
Subject: Re: [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: Sat, 14 Oct 2023 19:35:57 -0000

On Wed, 11 Oct 2023 at 21:04, Alan DeKok <aland@deployingradius.com> wrote:


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

I read through the draft. A couple of notes follow.

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?


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 -
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-02.html#section-3.3-12.1.3.1.4.1.1
        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:
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-02.html#section-3.3-17

   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 -
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-02.html#section-3.3.2-4.1.1
    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?
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-02.html#section-3.5-6

   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.


Fifth, there's a paragraph in section '6.4 Error-Cause Attribute' that
discusses Error-Cause in Access-Reject and its unknown origin.
https://www.ietf.org/archive/id/draft-ietf-radext-radiusv11-02.html#section-6.4-2

This may come from Radius -> Diameter translation. See the second last
paragraph in RFC 4005 section 9.1.1:
https://www.rfc-editor.org/rfc/rfc4005.html#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.


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.

-- 
Heikki Vatiainen
hvn@radiatorsoftware.com