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

Heikki Vatiainen <hvn@radiatorsoftware.com> Sun, 17 September 2023 20:40 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 46DB9C14CE55 for <radext@ietfa.amsl.com>; Sun, 17 Sep 2023 13:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.905
X-Spam-Level:
X-Spam-Status: No, score=-1.905 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_NONE=-0.0001, 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=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 sriCZknjzUlD for <radext@ietfa.amsl.com>; Sun, 17 Sep 2023 13:40:43 -0700 (PDT)
Received: from mail-wr1-x42d.google.com (mail-wr1-x42d.google.com [IPv6:2a00:1450:4864:20::42d]) (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 8A4CBC151070 for <radext@ietf.org>; Sun, 17 Sep 2023 13:40:43 -0700 (PDT)
Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3214d4ecd39so397291f8f.1 for <radext@ietf.org>; Sun, 17 Sep 2023 13:40:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20230601.gappssmtp.com; s=20230601; t=1694983241; x=1695588041; 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=amj9uBuFJHwUa/43/lMCSDHSCFNcuVGiEjeywJY5OX0=; b=R41ygo/GdeA4Clpx9XMsfrs9EDN+fSz1cysqia3DXbKlV3D6If+ZJHttdYQlyZJMF1 AqzyFGf1cRgk3FWPQSClwfgaLBcb8uz6WvspcQRpTrWxQyJZn3DNQReZ2Xhd929nA6BO vOvfSy6UFJVkppDxqv7YOH7RMotl9rWzrahi93mXw66IwGmHJIl03vaxKu0w7sy+tMJs rubIO/fgzgjXpDBie69vhAISJiI7L/hyGl7culRDgYHxHZh4NwVsq3H3gWOmJzUKbs5P FqS3J7X5jMyca0r553ziEYDr2WKr3J+wFlS9dvRqbspURbPvtZWrCc4kosD5e/HVFkiy axWg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694983241; x=1695588041; 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=amj9uBuFJHwUa/43/lMCSDHSCFNcuVGiEjeywJY5OX0=; b=c+Y7EmYf6LocLCMX3kZKshmjCx3ezC2EoC2jhsZH5S6o6nishKrqUW087NjJtAxkEj XUKCmRMo0pFfaPnk8CAAbey12roNVFc6FhPvrTmn8xFLLzeyCHlrU6vzTd8zJ68lDxOr wC+S1rmhTDhMZms0q7B6RQE+eNMiyMB3JiDsuETkSJe5YZ+9Dec/WQgz89u840yGfUcI O061BdDABKX17cE50LRiJLdt1Q94xwULWASyQIWobPNIfckrHwBdHMK5UfCOuGxM3zWQ ZPkC1WNKyMeS9NxcJyeGw5+neQkPAZkoVME00+TRmlsHcZeC2rKu0qpFnRTlQoeDQU3F ZwYw==
X-Gm-Message-State: AOJu0YwQUH7/+t0i060H5yF0GLL9wMsxAg9x33WBtlpeT0BmQDqsovAy qlErckpKwlwcxYE4Z2RA/Mr9K40jNml0MdTst21CVeVz2FX3SrHAamA=
X-Google-Smtp-Source: AGHT+IEFr3sIurcVIw80yECFQXMIfiG30gC/4mybXkmRKKm5fWtU7iTk62E5kpWED/kWlBPX0YIQL3glmhx2HHO0sig=
X-Received: by 2002:adf:f0c2:0:b0:317:eeaa:22cd with SMTP id x2-20020adff0c2000000b00317eeaa22cdmr6283445wro.37.1694983240792; Sun, 17 Sep 2023 13:40:40 -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>
In-Reply-To: <B88BB843-C4C3-418F-A6CA-4F360EB67C95@deployingradius.com>
From: Heikki Vatiainen <hvn@radiatorsoftware.com>
Date: Sun, 17 Sep 2023 23:40:24 +0300
Message-ID: <CAA7Lko_oL5Oy9T52JnwUiaZDvUhwed8hivysoSuqY1jhXF=Ziw@mail.gmail.com>
To: radext@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f7d9de0605940925"
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/xyVbbKUEFu6kpHEeKjRY1PytkYI>
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: Sun, 17 Sep 2023 20:40:48 -0000

On Fri, 1 Sept 2023 at 15:04, Alan DeKok <aland@deployingradius.com> wrote:

>   Can reviewers please check that the updated document addresses their
> concerns.  If so, I believe the document can move forward.
>

The document looks good to me. There's one general question I have about
what must be supported. I've also collected five points where I'd like to
see clarifications. The points do not attempt to change the behaviour
described in the document, only sharpen and enhance what the document says.

In general: What must be supported? Section 5. 'Guidance for RADIUS
Clients' states this:

> Client implementations MUST allow the use of a pre-shared key (TLS-PSK)
> for RADIUS/TLS.
>

Section 6. 'Guidance for RADIUS Servers' does not have a respective
statement. Likely the same requirement applies for servers too?

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've worked on an implementation and noticed that simultaneous support for
both PSK and certificate authentication is a bit tricky. RADIUS/TLS
requires TLS client certificate authentication. When this requirement is
combined with the differences between TLS 1.3 and 1.2, how they do PSK, how
they are implemented by TLS stacks, and how a stack requires these all to
be handled, at this point the simplicity of PSK is diminished. Being able
to support, for example, just TLS-PSK with TLS 1.3 would be much simpler
than requiring support for all TLS versions + PSK and certificate
authentication + session resumption.

In short: what are the minimum and suggested implementation requirements?


Here are the five points mentioned above, first:
Section 4.1. says:

> It is RECOMMENDED that systems follow the directions of [RFC9257] Section
> 4 for the use of external PSKs in TLS.
>

Should the section be Section 6 'Recommendations for External PSK Usage'
instead of Section 4?

Second:
Section 6 in RFC 9257 starts with the following text:

> 1. Each PSK SHOULD be derived from at least 128 bits of entropy, MUST be
> at least 128 bits long, ...
>

The draft says, section 4.1, that PSKs are required to be at least 16
octets (128 bits) in length. The draft does not say that anything about
bits of entropy, it only has requirements and recommendations for PSK
length. Further in section 4.1., the code sample pulls 12 octets (96 bits)
from a platform specific random source, and then encodes it to a 24 octet
representation.

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.

Also the code snippet in draft section 4.1 should be updated to read 16
octets with a note that the random source is assumed to provide one bit of
entropy for each bit that's read.

[1] https://en.wikipedia.org/wiki/Entropy_(information_theory)


Third:
Section 6.2 'Practices for TLS-PSK', first paragraph ends with:

> The PSK replaces the shared secret as proof of client authenticity and
> shared trust.
>

The previous section 6.1 'Current Practices' discusses the use of source IP
and shared secret with RADIUS/UDP. It might be useful to remind that before
RADIUS/1.1 the shared secret must still be used as it's used currently.
TLS-PSK doesn't change anything in that sense.

I like the analogy Section 6.2 introduces, but it could also be argued that
PSK replaces certificate and its identity and public key. When thought like
that, it's easier to see that the transported RADIUS remains the same no
matter how the TLS connection is authenticated and how its key exchange is
done.


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.
>

I'd replace the last sentence with similar text that's used in the last
paragraph of Section 5.1. It simply says that TLS-PSK must not be used
because it's not known how to do this.

OpenSSL 3.0 supports PSKs up to 512 octets (not bits)  which gives the
possibility to have strong PSKs. The current text in the draft would at
least require some justification if it is to be kept.


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.

--
Heikki Vatiainen
hvn@radiatorsoftware.com