Re: [radext] Shepherd review of draft-ietf-radext-tls-psk-03

Alan DeKok <aland@deployingradius.com> Wed, 22 November 2023 21:50 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 60CD6C15153E for <radext@ietfa.amsl.com>; Wed, 22 Nov 2023 13:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 Owmirj10GZzq for <radext@ietfa.amsl.com>; Wed, 22 Nov 2023 13:50:44 -0800 (PST)
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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2248C14CE4B for <radext@ietf.org>; Wed, 22 Nov 2023 13:50:43 -0800 (PST)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id 288305BD; Wed, 22 Nov 2023 21:50:40 +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: <f4dad0b1-fd9b-4034-a991-01e899e9bdb9@switch.ch>
Date: Wed, 22 Nov 2023 16:50:38 -0500
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <726A8EA6-CB71-4342-99FA-F8434AA1CABD@deployingradius.com>
References: <091b01da0cd0$570fb8f0$052f2ad0$@smyslov.net> <F75CF375-73B2-43C9-A047-6350FA2DFD8A@deployingradius.com> <09ca01da0d60$573d2f20$05b78d60$@smyslov.net> <CAA7Lko-r8pGYoewJwj-zPuy+ZGTn9_wPzusumyG_MdN50QKD5w@mail.gmail.com> <02d601da10a8$50f9a8a0$f2ecf9e0$@gmail.com> <f4dad0b1-fd9b-4034-a991-01e899e9bdb9@switch.ch>
To: Fabian Mauchle <fabian.mauchle@switch.ch>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/tUm2Ac-VnpwtsnqmnTmWj4gI5eQ>
Subject: Re: [radext] Shepherd review of draft-ietf-radext-tls-psk-03
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, 22 Nov 2023 21:50:48 -0000

On Nov 14, 2023, at 5:40 AM, Fabian Mauchle <fabian.mauchle@switch.ch> wrote:
> From the extensive discussions at the IETF118 we concluded that a server should reject a connection if it doesn't recognize the PSK identity as a configured client or as a resumption ticket; for the PSK identity is part of the server authentication.

  I'll make some changes to the doc and push them out.

> However, looking at the TLS spec (RFC8446), it does not mandate any mechanism how to create the session tickets and thus there is no guarantee that an implementation will be able to distinguish between externally established PSK and session resumption.
> I'm therefore reluctant to put an unconditional MUST on this.
> 
> My proposal therefore would be:

  I've written substantially more text explaining the issues.  :(

> 5.  Guidance for RADIUS Clients
> 
> (add to the end of the section, before 5.1)
> + If a client initiated a connection using a pre-shared key with TLS1.3
> + by inlcuding the pre-shared key extension, it MUST reject the
> + conneciton if the server did not select the pre-shared key to continue
> + the handshake.

  I've added that, thanks.

> 6.2.1.  Requirements for TLS-PSK

  I've reworked that substantially.  It should be a lot clearer.  And, allow the behaviour of OpenSSL.

  Alan DeKok.