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

Fabian Mauchle <> Tue, 14 November 2023 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A063C14CE4D for <>; Tue, 14 Nov 2023 02:40:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.106
X-Spam-Status: No, score=-7.106 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, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uh7O3WflgUeB for <>; Tue, 14 Nov 2023 02:40:45 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7E78C14CE53 for <>; Tue, 14 Nov 2023 02:40:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=2314; s=selector1; t=1699958445; h=message-id:date:mime-version:subject:to:references:from: in-reply-to:content-transfer-encoding; bh=1q5quMUT2GJ/lDb1ewRFAh8YW6ynbgPZJRCbY5a2HaY=; b=BOgwJvLSEgJR0mCoC32K2hSkNzq2O8FNjmsJDmG/7FTe5xgCvXu+hUmn jT40RX9XO7QmzulARGdlQEuR3j9Kz2fJUnKAWgaxgKyn1rG6VcB89/rVL EWF1PPdsIh5W/b2//Nl90Z3MAkt3G8WGNKlZXOzGE4mlibKa0L6a3icWZ k2CMUmBtox9HHPcUay3LT++gSN+iUH1QFImn1tdZrUieKJ+DP/B2BY+EM QxN3ao6fM5ZCuMNMykApyFo6y+jQPjMLzY3LuI1GSTIRUtwaoC91GeCDx EOhtxanYzzrg5ZczZJ6RKEnPT8IxiFIHmV1rEcba4IWCEn1Vc07OTzrtc w==;
X-IronPort-AV: E=Sophos;i="6.03,301,1694728800"; d="scan'208";a="5681945"
Received: from unknown (HELO ([]) by with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 14 Nov 2023 11:40:41 +0100
Received: from [] ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.39; Tue, 14 Nov 2023 11:40:40 +0100
Message-ID: <>
Date: Tue, 14 Nov 2023 11:40:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US, de-CH
References: <091b01da0cd0$570fb8f0$052f2ad0$> <> <09ca01da0d60$573d2f20$05b78d60$> <> <02d601da10a8$50f9a8a0$f2ecf9e0$>
From: Fabian Mauchle <>
In-Reply-To: <02d601da10a8$50f9a8a0$f2ecf9e0$>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Originating-IP: []
X-ClientProxiedBy: ( To (
Archived-At: <>
Subject: Re: [radext] Shepherd review of draft-ietf-radext-tls-psk-03
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: RADIUS EXTensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 14 Nov 2023 10:40:49 -0000

Hi all,

On 06.11.23 12:56, Valery Smyslov wrote:
> With TLS 1.3 a server can choose to not do PSK authentication and 
> continue the handshake with certificate authentication. If this is 
> desired, then 'Any connection from outside of the allowed range(s) MUST 
> be rejected' wouldn't work if certificate authentication for the non-PSK 
> address range is supported. Or if 'rejected' in this context simply 
> means that PSK is not used, then a clarification would be useful.
>              My understanding is that “MUST be rejected” here applies to 
> PSK cases only.
>              If the server falls back to certificates, then 
> “RECOMMENDED” below works.

 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.

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:

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.

6.2.1.  Requirements for TLS-PSK

   Finally, if a RADIUS server does not recognize the PSK identity or if
   the identity is not permitted to use PSK, then the server
+ MUST reject the connection unless it is configured for session
+ resumption. Since TLS 1.3 [RFC8446] uses PSK for resumption, a server
+ SHOULD colorize the session ticket and SHOULD only perform a full
+ handshake if the provided PSK is identified as a (possibly outdated or
+ invalid) session ticket the server handed out.


Fabian Mauchle
NOC:   +41 44 268 15 30
Direct:+41 44 268 15 39

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland