IETF Logo Mail Archive

Re: [radext] WGLC for draft-ietf-radext-tls-psk-04

Michael Richardson <mcr+ietf@sandelman.ca> Fri, 12 January 2024 23:44 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 E845AC14F689 for <radext@ietfa.amsl.com>; Fri, 12 Jan 2024 15:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 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_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 5ZiqXllWPPKH for <radext@ietfa.amsl.com>; Fri, 12 Jan 2024 15:44:07 -0800 (PST)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (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 AF7E2C14F61D for <radext@ietf.org>; Fri, 12 Jan 2024 15:44:07 -0800 (PST)
Received: from dyas.sandelman.ca (unknown [IPv6:2001:18c0:3a2:7500:adf4:af74:5f9:6a93]) by relay.sandelman.ca (Postfix) with ESMTPS id 404F41F455 for <radext@ietf.org>; Fri, 12 Jan 2024 23:44:05 +0000 (UTC)
Authentication-Results: relay.sandelman.ca; dkim=pass (2048-bit key; secure) header.d=sandelman.ca header.i=@sandelman.ca header.b="P4dllKD3"; dkim-atps=neutral
Received: by dyas.sandelman.ca (Postfix, from userid 1000) id 9860EA0B7F; Fri, 12 Jan 2024 18:43:46 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=sandelman.ca; s=dyas; t=1705103026; bh=CYQ4RAVCDY3LH/S4UtuMwRCLP3U7+dgT/DKE/DKO2SI=; h=From:To:Subject:In-reply-to:References:Date:From; b=P4dllKD3vpJYYZZRx9MUOifrBDe0Of9Thy8SpankHoRjnZxh0iPo01UbWDCJd4xPa EYTALTDa4teK8tcZKl0uV8IeICFPk+eGy9ZEyWvas5ic8Ot8QyBYwPTPumpNnye0pt gy7r0yhUJMHHr7nrtxkf4dGcCBkuvZPRBrVsX1D4XRnVOEdTmPBb6PPiSnDvUUKkPC pB0ImEBhtPdMZ/wu/9rzbuCuc0i07sxgQ+rjCoJq/mQc89L9cx6EQ7OA72c7Ty4AJf 3VU3t7j5Ocq5xMrDJZWg8IwmHgWKFBw+nyg3tIucDUTowufx+UT3ULxnJbNFX4iIaJ d7rp+cJzfxItg==
Received: from dyas (localhost [127.0.0.1]) by dyas.sandelman.ca (Postfix) with ESMTP id 95B5CA0B7D for <radext@ietf.org>; Fri, 12 Jan 2024 18:43:46 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: radext@ietf.org
In-reply-to: <57B035CF-64CA-4B93-9FEE-929D7DD80D32@deployingradius.com>
References: <005901da242e$f623d550$e26b7ff0$@smyslov.net> <6172ba00-6793-4393-9466-37b52fe1e25b@switch.ch> <651E26F6-B0B2-40A7-B636-88569CFEFCB3@deployingradius.com> <e34c5a26-079d-4988-83b0-c53c3708ef2e@switch.ch> <57B035CF-64CA-4B93-9FEE-929D7DD80D32@deployingradius.com>
Comments: In-reply-to Alan DeKok <aland@deployingradius.com> message dated "Fri, 12 Jan 2024 16:43:42 -0500."
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.3
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Fri, 12 Jan 2024 18:43:46 -0500
Message-ID: <1766002.1705103026@dyas>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/jvLyb_TEIcU2O5Hv7Jes8YA7rbI>
Subject: Re: [radext] WGLC for draft-ietf-radext-tls-psk-04
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 Jan 2024 23:44:12 -0000

Alan DeKok <aland@deployingradius.com> wrote:
    > - PSK identities are opaque blobs, and must be supported as such
    > - PSK identities used for resumption are automatically generated, so no
    > one cares what they are

    >   The server has to be able to distinguish between them.  IIRC from the
    > hallway conversations in Prague, the server must simple "make them
    > different" somehow, using a method up to the server.  It can then
    > either examine the PSK identity to determine resumption (or not).  Or,
    > the server can examine a database to determine if the identity is
    > resumed (or not).

It seems like a server that is assigning identities for resumption might like
to use invalid UTF-8 there then?
...
That keeps the resumption tickets out of the database, and keeps them more stateless?

    >   The difference for the server is that the resumed PSK session must
    > re-use (or re-run) the cached policies from the original session.  It
    > therefore likely needs to associate the original PSK identity with the
    > resumption identity.

But, that original identity could be encrypted into the resumption ticket, right?


--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-                      *I*LIKE*TRAINS*

v2.23.0 | Report a Bug | By Email