IETF Logo Mail Archive

Re: [radext] Server identity and RFC7585bis (was: Review of draft-ietf-radext-radiusdtls)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 10 April 2024 19:56 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 54275C14F5E6 for <radext@ietfa.amsl.com>; Wed, 10 Apr 2024 12:56:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.097
X-Spam-Level:
X-Spam-Status: No, score=-7.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=sandelman.ca
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 12BSyvpBA94D for <radext@ietfa.amsl.com>; Wed, 10 Apr 2024 12:56:18 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (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 ietfa.amsl.com (Postfix) with ESMTPS id 4F8D4C14F6A2 for <radext@ietf.org>; Wed, 10 Apr 2024 12:56:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6EA0E3898D; Wed, 10 Apr 2024 15:56:08 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 4y_wT91rEzMt; Wed, 10 Apr 2024 15:56:07 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C3EA63898C; Wed, 10 Apr 2024 15:56:07 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1712778967; bh=EcO+CfQpS0BMLtJmhTN9GmAJi/PVRw4NF3u3hwmG6/c=; h=From:To:Subject:In-Reply-To:References:Date:From; b=e9wLcMMCNYJdMBpXkOyXY3VGFOwq9lKAt3B1qPbg+PkjR2vP1zoxEbUCpsosMq6+f tO7VL+eJyoYA9qWPHV2I4pcRwtwfYPuC9Q3oZt/FnBE88+1M+otAfLy6xRCWWjRtc7 HngU15gu7li+Yo7GV0fdZOWPJEubzBK82+Xt2WXrr70T2BIMOv1Ny+/LDPFUsKGniD um6zXo6HPC3Athtz2t0evEdJRMt81acxHtPaYwTHVJBicnnGSsPgiRZIk3OiePsaKv 3dprdwZL8q67HfgxeJDC1+F3AVYb/eIOSjwkcyTczuAmqngSxnlNkuQIh76eoJficP kop2AS5/PfFnw==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BEFEBF15; Wed, 10 Apr 2024 15:56:07 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Jan-Frederik Rieckers <rieckers@dfn.de>, radext@ietf.org
In-Reply-To: <6628c5c8-5071-476f-9ea2-2875d86304e2@dfn.de>
References: <CA9BEA9C-39EF-4764-A0FE-D122413B37F7@deployingradius.com> <18ef8267-474e-49ae-9204-0c6c79d5e50c@dfn.de> <6628c5c8-5071-476f-9ea2-2875d86304e2@dfn.de>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 10 Apr 2024 15:56:07 -0400
Message-ID: <10347.1712778967@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/b34JK4JMGHuOIxRTOfvi_I_ff0w>
Subject: Re: [radext] Server identity and RFC7585bis (was: Review of draft-ietf-radext-radiusdtls)
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, 10 Apr 2024 19:56:22 -0000

Jan-Frederik Rieckers <rieckers@dfn.de> wrote:
    > On 20.03.24 03:55, Jan-Frederik Rieckers wrote:
    >>>     ... If a RADIUS/(D)TLS client has multiple connection to a server, it
    >>> MUST NOT decide to mark the whole server as DOWN until all connections to
    >>> it have been marked DOWN.
    >>>
    >>>    Maybe add a discussion of what, exactly, is a "server". Destination
    >>> IP?  How is this affected by RFC 7585 dynamic DNS lookups?
    >> I've added a TODO for after the IETF.

    > I've started to write a section to explain how a server is uniquely
    > identified, but I am failing to come up with anything other than destination
    > IP address and destination port.
    > Is there some better qualifier?

    > I'm not sure if this warrants a whole section "Server Identity" which
    > basically just says "If it's the same IP addr and port, its the same server".

You need to give the certificate SAN dNSName for the server, or you can't
verify the certificate correctly.

I think that "same IP addr and port" is a bad test for same server, as one
way to do multi-tenant would be to inspect the SNI and punt to different
backend servers.
(I'm not saying it's the good strategy, but given the way some servers are
licensed, it might be the most economic)

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

v2.23.0 | Report a Bug | By Email