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

josh.howlett@gmail.com Sat, 12 August 2023 11:53 UTC

Return-Path: <josh.howlett@gmail.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 0EB64C17EE09 for <radext@ietfa.amsl.com>; Sat, 12 Aug 2023 04:53:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, FREEMAIL_FROM=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UzkVw1SnbaWw for <radext@ietfa.amsl.com>; Sat, 12 Aug 2023 04:53:13 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 32139C151534 for <radext@ietf.org>; Sat, 12 Aug 2023 04:53:13 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id ffacd0b85a97d-31765aee31bso2308774f8f.1 for <radext@ietf.org>; Sat, 12 Aug 2023 04:53:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691841191; x=1692445991; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:to:from :from:to:cc:subject:date:message-id:reply-to; bh=upi1Oj1X0TwBOQLDI6y64y4rB8613+YsmHwuEFetkVI=; b=SUl9NwKqLNEZzlOH8uDjZrp5ysL77vSk2n6cHUwOh9iZJelO7jEyI4uOaAzHW12ajd nIw/exhTNcSIBQeaejDHGOO5O4HLLWG3cNiveevYVPw1MUywafIdgCoHP4jtc9peqfaV lUS/pPu+VqnLTmlqAXAvmWbYP3X0qUA71o+hXe0y6RaujBo4OiFLaWRIAcCRCeFlRV3q LLK7QlWKyXzCzwyTLGgf+J8OTzWuP0v/p1UWwecs3MTRvjbcYP8CNkfVukaTp9pKnyOx uPmfNHxowDG38tqfHCcnNRjQ0/uwKFBGgN/sXhBPxCWLfgytxExFAC0lb3ezmH1nFa99 oWEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691841191; x=1692445991; h=content-language:thread-index:content-transfer-encoding :mime-version:message-id:date:subject:in-reply-to:references:to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=upi1Oj1X0TwBOQLDI6y64y4rB8613+YsmHwuEFetkVI=; b=JCl3qMru2UgBtpSsARAVLAZiBNvBr9m3FlWfV8AgIfhoKLtS6ayooRFXKqSBAgpvqF l0LSj/DBlH4nmN48bX+TpLsLThhB+GZeRNp2slHrlwK08myEAxeY9oOlEuNX74RuAm40 nmUjLspy2KIdC82l+5RrIc9uHQP8YrXTPYuzh9nw+If+MNUowm6mkq9TBgE6SyU6vIbH LIc78BtKrdmpvM36D1q4+4T8jGlKh7WULPvxADOJitUjsN42rC+EnFlx6ZoNk9dDGEVS 4dAKFJ7GKQkKm7T5oUGGXqPynhDZoOh/kMICh0E8S8YUKKJHDZ0xcodGYZ0/m5iVGltF pZcQ==
X-Gm-Message-State: AOJu0YzqMyks3JeMoXSAySc74jTo8E0hKI9t9g42Z/MFzZldEoFEWOVi XuxcfavwyNriclAngevK9W6mIZZXTAOm9A==
X-Google-Smtp-Source: AGHT+IE5rxg0i4PfDmbjndf5LDqioCdZhB4izGZnzdDJsyjUYEXziIm1darqHM6ejnbbQ+T+BJN2RQ==
X-Received: by 2002:a5d:40ce:0:b0:317:690e:7b39 with SMTP id b14-20020a5d40ce000000b00317690e7b39mr3263485wrq.12.1691841190818; Sat, 12 Aug 2023 04:53:10 -0700 (PDT)
Received: from TABLET7VKS5QAO (host81-142-222-159.in-addr.btopenworld.com. [81.142.222.159]) by smtp.gmail.com with ESMTPSA id n12-20020a5d420c000000b0031274a184d5sm8379065wrq.109.2023.08.12.04.53.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 12 Aug 2023 04:53:10 -0700 (PDT)
From: josh.howlett@gmail.com
To: 'Jan-Frederik Rieckers' <rieckers@dfn.de>, radext@ietf.org
References: <75bd413f-35be-3727-ce6d-51bb6ca01134@dfn.de>
In-Reply-To: <75bd413f-35be-3727-ce6d-51bb6ca01134@dfn.de>
Date: Sat, 12 Aug 2023 12:53:10 +0100
Message-ID: <009301d9cd13$915a30a0$b40e91e0$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHN3ckFIrilH3PSuro+2kzN1tUdI6/+adHw
Content-Language: en-gb
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/phzGzgitNaprJdY0FDDNdUZUvsw>
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: Sat, 12 Aug 2023 11:53:17 -0000

Hi Jan-Fred,

I support this.

Josh

> -----Original Message-----
> From: radext <radext-bounces@ietf.org> On Behalf Of Jan-Frederik Rieckers
> Sent: Friday, August 11, 2023 11:03 AM
> To: radext@ietf.org
> Subject: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models
> 
> Hi to all,
> 
> after reading the TLS-PSK draft and following some of the discussion about this
> and the deprecation of RADIUS/UDP RADIUS/TCP, a new question came up for
> me regarding the RADIUS/(D)TLS-bis draft:
> 
> We want to help move people towards secure transports, and TLS-PSK is a
> good way to do that, especially if people already have a process for sharing the
> RADIUS shared secret, and this process could be easily adapted to sharing the
> PSK ID and the PSK.
> 
> RADIUS/(D)TLS currently mandates that both server and client implement
> certificates with the PKIX trust model.
> 
> My idea from the top of my head:
> 
> We have had discussion about the Requirement for TLS/DTLS on the client side
> an have reached a consensus, as far as I read the list, that the server should
> support both, but the clients can choose to implement only one.
> Would it be a good idea to continue this with the mutual authentication as
> well?
> 
> The idea would be: RADIUS/(D)TLS servers MUST implement certificates with
> PKIX trust model and TLS-PSK, RADIUS/(D)TLS clients MUST implement at
> least one of those two.
> 
> This way we still ensure complete compatibility, but RADIUS clients that
> currently only support RADIUS/UDP with shared secrets can upgrade to
> RADIUS/(D)TLS easily without the need to implement a whole PKIX certificate
> validation stack.
> 
> However, this is a significant change in the spec, since RFC 6614 did not
> mandate TLS-PSK.
> 
> Implementation status, as far as I know:
> 
> * FreeRADIUS implements TLS-PSK for RadSec
> * Radsecproxy just became capable in the current master, will probably be
> released in the 1.11 version.
> 
> I have not checked RADIATOR and I'm not sure if there are more RADIUS/TLS
> implementations out there.
> 
> 
> Cheers,
> Janfred
> 
> --
> Herr Jan-Frederik Rieckers
> Security, Trust & Identity Services
> 
> E-Mail: rieckers@dfn.de | Fon: +49 30884299-339 | Fax: +49 30884299-370
> Pronomen: er/sein | Pronouns: he/him
> ___________________________________________________________________
> _______________
> 
> DFN - Deutsches Forschungsnetz | German National Research and Education
> Network
> Verein zur Förderung eines Deutschen Forschungsnetzes e.V.
> Alexanderplatz 1 | 10178 Berlin
> www.dfn.de
> 
> Vorstand: Prof. Dr. Odej Kao (Vorsitzender) | Dr. Rainer Bockholt |
> Christian Zens
> Geschäftsführung: Dr. Christian Grimm | Jochem Pattloch
> VR AG Charlottenburg 7729B | USt.-ID. DE 1366/23822