Re: [radext] Server identity and RFC7585bis

Alan DeKok <aland@deployingradius.com> Fri, 12 April 2024 14:40 UTC

Return-Path: <aland@deployingradius.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 00AF3C14F5E4 for <radext@ietfa.amsl.com>; Fri, 12 Apr 2024 07:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XKw0kmGy4cpB for <radext@ietfa.amsl.com>; Fri, 12 Apr 2024 07:39:58 -0700 (PDT)
Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (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 ietfa.amsl.com (Postfix) with ESMTPS id CAAFDC14E515 for <radext@ietf.org>; Fri, 12 Apr 2024 07:39:58 -0700 (PDT)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id 613DF3F2; Fri, 12 Apr 2024 14:39:55 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <548E18B4-77BB-4658-B17D-56212F324436@deployingradius.com>
Date: Fri, 12 Apr 2024 10:39:53 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <42665AEE-C6A2-489F-BFFC-0977F0DCA84F@deployingradius.com>
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <18ef8267-474e-49ae-9204-0c6c79d5e50c@dfn.de> <6628c5c8-5071-476f-9ea2-2875d86304e2@dfn.de> <10347.1712778967@obiwan.sandelman.ca> <7D282A57-B68E-43DA-A6A2-7E14A8C09119@deployingradius.com> <5b5d0dc0-a81a-415e-ac01-de8b365a6ea0@dfn.de> <548E18B4-77BB-4658-B17D-56212F324436@deployingradius.com>
To: Jan-Frederik Rieckers <rieckers@dfn.de>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xTgloDKTjFPahPFf45vYbQdYOPc>
Subject: Re: [radext] Server identity and RFC7585bis
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: Fri, 12 Apr 2024 14:40:00 -0000

  So summarize my thoughts a little more clearly;

RFC 7585 clients SHOULD use SNI.  This information can be used by a server which handles multiple realms, in order to present a matching certificate for that realm.

Other TLS clients MAY use SNI.  The SNI realm SHOULD be configured by the administrator of the RADIUS client.  The SNI realm does not need to be the same as any realm in packets sent by the client.

TLS connections MUST operate application-layer watchdog checks as per RFC 3559 Section 3.4.  TLS connections SHOULD also enforce idle timeouts, lifetimes, etc.

TLS connection liveliness checks MUST be applied on a per-connection basis.  There may be other connections to the same destination which are up and active.

Other issues of load-balancing, multiple connections to the same destination, etc. are outside of the scope of this document.

  Alan DeKok.