Re: [radext] I-D Action: draft-ietf-radext-tls-psk-03.txt

Heikki Vatiainen <hvn@radiatorsoftware.com> Tue, 19 September 2023 16:51 UTC

Return-Path: <hvn@radiatorsoftware.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 865A1C16B1E5 for <radext@ietfa.amsl.com>; Tue, 19 Sep 2023 09:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=radiatorsoftware-com.20230601.gappssmtp.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 vFUH1TX1Wkbg for <radext@ietfa.amsl.com>; Tue, 19 Sep 2023 09:51:34 -0700 (PDT)
Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 A8D47C1519A2 for <radext@ietf.org>; Tue, 19 Sep 2023 09:51:32 -0700 (PDT)
Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-52e5900cf77so7351236a12.2 for <radext@ietf.org>; Tue, 19 Sep 2023 09:51:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20230601.gappssmtp.com; s=20230601; t=1695142291; x=1695747091; darn=ietf.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=EKNuHEqSUV2Ut5gGACHimDotfewlt5tpLASpwF2Lc8c=; b=B+ptCrQeJTGV+HRCtITUBY30p7ajNC6b0HFi0dIQeuX4mwJGjcvQiBMDJtjYf+F8dM 2RlBR5JtMGOgwkD/ZfBfcTtnK5XYwRcz8c6c4ADZKxOjMzYc/29aNhsnJvPuhegMqxRo 7dCz3/lEtKdELpw/arOXM9EcxFO8CB/gPJnL1zEUWrsis6tiXxQHeCJtzIflDuWzBcpQ avi+rezRN4MmFToTaw9H+gKXnu8s6Cnxjgnq49kMzp9oidqQBlPJ7hYVwYj5E1kb3iYc rxQuRW1XJbB6pOIujl3e8430YXD3ZrUWJkHHM8V3qgrXOm9XMcXhU6992YPmbh8aSrpU 3s0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1695142291; x=1695747091; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=EKNuHEqSUV2Ut5gGACHimDotfewlt5tpLASpwF2Lc8c=; b=JQ8n454k0s9lD/jXMhUdDS1izBc07W9dENLLIW4PEnKcWMGFUCG6+owii69HZ8f9Ex ZGoXqUGj49F1Zp1LJEeMEMMGu2F0YN9eAUbJckVWHDPJT27mzdgGXRMDqHCFYSzkl2Ht m4x5IPlXVgcYYSHJ7iMznWGQS21lwnhJG1TeWmohCAlhT94M+/gJk7FWr3+w837A7BqE Dwe1BLsDr+PqFraYfxMEQzxm/as4KPYUoDH+lLjuMAguUKKN1xeGbvAw7i5ePfaiGktO Q3HoL/sBhQqH6bkfxRxx3rWLKWwK9oSR3W8IreF+YXz78h6jdpf0kJAT6PLH0+tcvlXP 0HbA==
X-Gm-Message-State: AOJu0YzEKZDQk9NeiusGgyrWMuba5uken4bmjTjttKafGvQbOmpp3umx 9lP3mvpQBzD/1qX+xx6DHl28iIIQAuk3qgymN77KV6hsazZES1mWIIA=
X-Google-Smtp-Source: AGHT+IFoGoJfG55PEiRseYMXc4qz4DcpVOto6kJK48wA53HDwQHA3wU/F5TZBJpkx2+95aLIpAzIDM8eJQ9QQnOT+J4=
X-Received: by 2002:a50:fa8b:0:b0:527:3a95:5bea with SMTP id w11-20020a50fa8b000000b005273a955beamr24443edr.32.1695142290796; Tue, 19 Sep 2023 09:51:30 -0700 (PDT)
MIME-Version: 1.0
References: <169290062850.51444.4789101133837195921@ietfa.amsl.com> <EFF9D14C-6714-4168-8C2D-A03DCB9ADFFB@deployingradius.com> <B88BB843-C4C3-418F-A6CA-4F360EB67C95@deployingradius.com> <CAA7Lko_oL5Oy9T52JnwUiaZDvUhwed8hivysoSuqY1jhXF=Ziw@mail.gmail.com> <8081E8F9-3818-43ED-8C82-3EBB093BCDBB@deployingradius.com>
In-Reply-To: <8081E8F9-3818-43ED-8C82-3EBB093BCDBB@deployingradius.com>
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Tue, 19 Sep 2023 19:51:14 +0300
Message-ID: <CAA7Lko8sDWY1nJxn1BkG0M1pLRuoOQhvnZvorLgZxBEBdzLPbA@mail.gmail.com>
To: radext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000164ad20605b91289"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/Zw28SAVTuVbomPrpj8TaoSyPxlI>
Subject: Re: [radext] I-D Action: draft-ietf-radext-tls-psk-03.txt
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: Tue, 19 Sep 2023 16:51:35 -0000

On Mon, 18 Sept 2023 at 20:46, Alan DeKok <aland@deployingradius.com> wrote:

> On Sep 17, 2023, at 4:40 PM, Heikki Vatiainen <hvn@radiatorsoftware.com>
> wrote:
> > The document also doesn't say which TLS versions must be supported. Is
> TLS 1.2 and earlier required too? Further, does the same server instance
> have to support both PSK and certificate authenticated TLS connections?
>
>   I'm happy to require TLS 1.3 and later.  I believe that the same server
> instance should support both PSK and certificate authenticated TLS
> connections.
>

It's likely what's sometimes needed but is likely not the most common case,
though. It sort of doubles maintenance work since both certificates and
PSKs are now in use. I'm fine with requiring TLS 1.3, and allowing TLS 1.2
and earlier, with recommendation to support PSK and certificate
authentication. Is something similar needed for clients too? Or is this
best left for implementations to decide?

> Suggestion: be more specific and state, for example, that a minimum
> length PSK is sufficient only when it is pulled from a random source that
> provides 'uniformly and randomly generated' [1] output and therefore
> provides the required amount of entropy. In other words, the PSK length
> after UI encoding does not satisfy PSK length requirements and the entropy
> of the PSK must be considered first. I'm not a crypto expert, therefore I
> don't feel confident to suggest a more exact text update.
>
>   Sure.  We could require that implementations only permit the entry of
> PSKs as hex values.  But that seems a bit too specific, I think.
>

I'd also say that's too specific. What's important is the length of the raw
PSK and it's randomness qualities. If the draft is clear about this, then
the implementations can use UI encoding they choose. The length of PSK
representation UI uses must not be understood as the length of the PSK.


> > Fourth:
> > The third paragraph in section 6.2 states the following:
> > In most situations a RADIUS server does not need to allow connections
> from the entire Internet. Where such connections are required, as with
> [RFC7585] or with a roaming consortium, TLS-PSK MUST NOT be used. It is
> significantly easier for an attacker to crack a PSK than to forge a client
> certificate.
>


>    Perhaps "Where TLS-PSK is used across the Internet, PSKs MUST contain
> at least 256 octets of entropy.".
>

That would give good guidance and clarify how to avoid PSKs being easier to
be cracked.


> Fifth:
> > The last paragraph in Section 6.2.1 'Requirements of TLS-PSK' is:
> > Finally, if a RADIUS server does not recognize the PSK identity or if
> the identity is not permitted to use PSK, then the server MAY proceed with
> a certificate-based handshake. Since TLS 1.3 [RFC8446] uses PSK for
> resumption, another use-case is that the PSK identity used for resumption
> may be rejected, in which case a full handshake is performed.
> >
> > The meaning of the second sentence is unclear to me.
>
>   Perhaps:
>
> Since TLS 1.3 {{RFC8446}} uses PSK for resumption, any unrecognized PSK
> identity MUST result either in a full certificate-based TLS handshake being
> performed, or in the TLS connection being rejected.
>

That's clear now. Thanks!

-- 
Heikki Vatiainen
hvn@radiatorsoftware.com