Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models

Alan DeKok <aland@deployingradius.com> Sun, 13 August 2023 20:43 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 7C0D4C14CE2F for <radext@ietfa.amsl.com>; Sun, 13 Aug 2023 13:43:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.906
X-Spam-Level:
X-Spam-Status: No, score=-6.906 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, 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 mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsZBvsNp87cX for <radext@ietfa.amsl.com>; Sun, 13 Aug 2023 13:43:05 -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 8087AC14F74A for <radext@ietf.org>; Sun, 13 Aug 2023 13:43:05 -0700 (PDT)
Received: from smtpclient.apple (135-23-95-173.cpe.pppoe.ca [135.23.95.173]) by mail.networkradius.com (Postfix) with ESMTPSA id 16F03268; Sun, 13 Aug 2023 20:43:01 +0000 (UTC)
Authentication-Results: NetworkRADIUS; dmarc=none (p=none dis=none) header.from=deployingradius.com
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.1\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <CD310A93-BAEA-47AF-B0F4-F72F59E12E11@gmail.com>
Date: Sun, 13 Aug 2023 16:43:00 -0400
Cc: Josh Howlett <josh.howlett@gmail.com>, Jan-Frederik Rieckers <rieckers@dfn.de>, radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <071626FC-C886-4B56-8EDA-D75BFF6D85B8@deployingradius.com>
References: <368D0314-E535-4176-A844-1FA378A4A1AA@deployingradius.com> <CD310A93-BAEA-47AF-B0F4-F72F59E12E11@gmail.com>
To: Margaret Cullen <mrcullen42@gmail.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/Hy6bDhUXldBNyiMz_U-3S_hqGdI>
Subject: Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models
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: Sun, 13 Aug 2023 20:43:09 -0000

On Aug 13, 2023, at 1:38 PM, Margaret Cullen <mrcullen42@gmail.com> wrote:
>> That is a tried and true RADIUS tradition.  "I know the RFCs say to do X, but I'll just do something else instead."
> 
> That tradition extends well beyond RADIUS, unfortunately.

   True.

> I think RADIUS/DTLS is an awful lot to expect, though — especially because I don’t see any evidence that RADIUS/DTLS will ever be widely implemented or used.  Do you?

  radsecproxy implements it.  I plan on implementing it soon in FreeRADIUS.

  Cisco supports it: https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst3850/software/release/16-3/configuration_guide/b_163_consolidated_3850_cg/b_163_consolidated_3850_cg_chapter_01100010.pdf

  There's not a lot of information on other implementations.

> Many protocols that run over TLS don’t have a DTLS equivalent defined, at all.  Is there some important advantage that RADIUS/DTLS offers that RADIUS/TLS does not?  Is that advantage sufficient to warrant mandating both in every server implementation?

  UDP is generally a much better transport for RADIUS than TCP.  So DTLS is likely to have fewer problems than TLS, for the same reasons.

>> There's good reason for that, of course.  But I think it's best to document the system we need, rather than the system we have.
> 
> I absolutely agree with this when it comes to documenting good protocol behavior, ways to avoid known issues, etc.  I don’t think it extends to mandating the implementation of an entirely separate protocol.
> 
>> The alternative is to never fix RADIUS, or to give bad implementations a free pass.
> 
> Is there a reason that you think a RADIUS/TLS-only server would be a bad implementation, and that it would  become a good implementation if it also implemented RADIUS/DTLS?

  Mainly due to UDP versus TCP issues.

 I can't recall a customer deployment where we did RADIUS over TCP.  The choices for secure networks (VPN, etc) are UDP.  RADIUS/TLS is used only as a security layer for packets being sent over the Internet.

  I think if DTLS was widely available, I would recommend that people prefer it to TLS pretty much all of the time.  The ALPN draft only makes this difference more pronounced in favour of UDP, I think.

  Alan DeKok.