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

Alan DeKok <aland@deployingradius.com> Mon, 18 September 2023 17:46 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 3FF01C14CE3F for <radext@ietfa.amsl.com>; Mon, 18 Sep 2023 10:46:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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
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 VEY2lTqvR2o5 for <radext@ietfa.amsl.com>; Mon, 18 Sep 2023 10:46:39 -0700 (PDT)
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 CAF9EC14F74A for <radext@ietf.org>; Mon, 18 Sep 2023 10:46:37 -0700 (PDT)
Received: from smtpclient.apple (unknown [75.98.136.130]) by mail.networkradius.com (Postfix) with ESMTPSA id C07684F3; Mon, 18 Sep 2023 17:46:34 +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: <CAA7Lko_oL5Oy9T52JnwUiaZDvUhwed8hivysoSuqY1jhXF=Ziw@mail.gmail.com>
Date: Mon, 18 Sep 2023 13:46:33 -0400
Cc: radext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8081E8F9-3818-43ED-8C82-3EBB093BCDBB@deployingradius.com>
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>
To: Heikki Vatiainen <hvn@radiatorsoftware.com>
X-Mailer: Apple Mail (2.3696.120.41.1.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/ydTUS1Cp17ZSCtjL5UnCv1OAabw>
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: Mon, 18 Sep 2023 17:46:41 -0000

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.

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

  I agree.  Unless there are substantive objections, I'm happy to require TLS 1.3 or later.

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

  Ues.

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

  I'll fix that.

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

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

  Sure.

> 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'll add some text here, and in 6.2

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

  Sure.  I'll add some text.

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

  I think the issue of RFC 7585 dynamic discovery is different.  i.e. I could allow RADIUS clients from 0/0, and then identify them by PSK identity.  But this would be a very bad idea.  I'll clarify some text.

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

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

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


  Alan DeKok.