From hvn@radiatorsoftware.com Thu Nov 2 02:43:36 2023 Return-Path: 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 E86C5C1516F3 for ; Thu, 2 Nov 2023 02:43:36 -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_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 wRChR87jWR1T for ; Thu, 2 Nov 2023 02:43:32 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 296E0C14F748 for ; Thu, 2 Nov 2023 02:43:31 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-53df747cfe5so1143936a12.2 for ; Thu, 02 Nov 2023 02:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=radiatorsoftware-com.20230601.gappssmtp.com; s=20230601; t=1698918210; x=1699523010; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=J2boFJiFYl4r6bVThdYx8GkdxZUqFaTKfw/H93nMZIU=; b=QXpv6w2savOOmxuYFxXQwOLTC6lILQmkMhSMtlNXhZ1fbwZ3gGb3rl5n4UVTXQ1XAQ ZviOoToO2nywmdOwuuFOyr4m1GEWMI28phJh5xXrUdR3WE8HXu5qnRojIz84TWuJ0b1t OBJony7G8n3g2oCrazp5xhzXXpMuC1efHQvib0+I7gvQUGJGcBmPfYrDBh1wXsJKtIwy Omg8Twg87UTIY6bXNbjCiwCW8Nto3XXmY1gfIIAq/mpt8xSYOE+YToDVippvbCEFKMYB psHtU6K5+z1chETaBKS+2zCdHMYmCquddHbUrYMM7JtS9G+AXs3Qk8u35W2X5JK3Z6j0 j1HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1698918210; x=1699523010; h=cc: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=J2boFJiFYl4r6bVThdYx8GkdxZUqFaTKfw/H93nMZIU=; b=YM7NcUtOFXfwSUqQwq8e94yKkY3c7fPbm7dQaLtYbo7nLsvGncELrfcA4mNa6wI4Gp TNOMmpsNYZ9AOly2/8maupEji/2E+S+kEeSpF+AcB0Og/ijmq3+1tJOamAnu+osU4Hio cZvwTeMYUxMiIj0oJg8815oaXDXVAcTkabwrrP7UFVnH06bD13HylNqT5xAFdQPtYbuf BTE2dXvdpG/DKdoiGffKREckPwngzRrehtbizXkFm5gZLqmja1fpTyTjWZ8ZTWYkuj+K Qak4OD267GLkH4LhSJNmILfOcdGfajXRZuQMAIyg7Dz9mJd7boHqGK4zUedpGj3d/X2F 5ZPQ== X-Gm-Message-State: AOJu0Yx9rLSqkDogVhzKsBJ55T3AcHS7/f5NqRao+tKJfWM74cK5A3lJ 0ztCZu1XVwujp9RFvYs37amjTPa4+0oi4oQQPeC8dlwYQQzUb8HTW+w= X-Google-Smtp-Source: AGHT+IE45Bdf5qtZHBWuzMp/TXFJnFkvwWROMg5AQRH7dKTHPvoLJpz4+S5wDscGQ6/j3JrORZSMUCeEgmgU4IXKHzM= X-Received: by 2002:aa7:d402:0:b0:540:fcc5:3ada with SMTP id z2-20020aa7d402000000b00540fcc53adamr15559545edq.9.1698918210095; Thu, 02 Nov 2023 02:43:30 -0700 (PDT) MIME-Version: 1.0 References: <091b01da0cd0$570fb8f0$052f2ad0$@smyslov.net> <09ca01da0d60$573d2f20$05b78d60$@smyslov.net> In-Reply-To: <09ca01da0d60$573d2f20$05b78d60$@smyslov.net> From: Heikki Vatiainen Date: Thu, 2 Nov 2023 11:43:13 +0200 Message-ID: To: radext@ietf.org Cc: radext-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000006a5d3f0609283871" Archived-At: Subject: Re: [radext] Shepherd review of draft-ietf-radext-tls-psk-03 X-BeenThere: radext@ietf.org 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: Thu, 02 Nov 2023 09:43:37 -0000 --0000000000006a5d3f0609283871 Content-Type: text/plain; charset="UTF-8" On Thu, 2 Nov 2023 at 09:44, Valery Smyslov wrote: > How about: > > > > A server supporting this specification MUST be configurable with a set > of "allowed" network ranges from > > which clients are permitted to connect. Any connection from outside of > the allowed range(s) MUST be > > rejected before any PSK identity is checked. It is RECOMMENDED that > servers support IP address > > filtering even when TLS-PSK is not used. There are few reasons for a > server to have a default > > configuration which allows connections from any source IP address. > > I think this text still doesn't address my point. The point is that servers > may support both this specification and certificates. In this case > they should be able to only filter out IP addresses for those clients, > which are connecting with TLS-PSK and should be configurable > to allow any IP address for clients wishing to use certificates. > > How about: > > A server supporting this specification MUST be configurable with a set of > "allowed" network ranges from > which clients wishing to use TLS-PSK are permitted to connect. Any > connection from outside of the allowed range(s) MUST be > rejected before any PSK identity is checked. It is RECOMMENDED that > servers support IP address > filtering even when TLS-PSK is not used. There are few reasons for a > server to have a default > configuration which allows connections from any source IP address. > > (MUST filter for TLS-PSK and RECOMMENDED for other cases). > 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. Should the text say that TLS-PSK must not be used and server must either do continue with server certificate authentication or reject the connection completely? Here's what server can do with TLS 1.3 when using OpenSSL: https://www.openssl.org/docs/manmaster/man3/SSL_CTX_set_psk_find_session_callback When an attempt to use PSK is detected by the server, a callback function is called. The callback can: 1. Return success and provide a PSK for PSK authentication 2. Return success but provide no PSK and authentication can continue * 3. Reject failure to terminate the handshake * If the server has configuration for server certificate authentication, then handshake continues with certificate. The server can also be configured without certificates and in this case the handshake is terminated because it can't continue. I observed this while working on implementing this draft. -- Heikki Vatiainen hvn@radiatorsoftware.com --0000000000006a5d3f0609283871 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, 2 Nov 2023 at 09:44, Valery Smysl= ov <valery@smyslov.net> wro= te:

>=C2=A0 =C2=A0How about:
>
> A server supporting this specification MUST be configurable with a set= of "allowed" network ranges from
> which clients are permitted to connect.=C2=A0 Any connection from outs= ide of the allowed range(s) MUST be
> rejected before any PSK identity is checked.=C2=A0 It is RECOMMENDED t= hat servers support IP address
> filtering even when TLS-PSK is not used.=C2=A0 There are few reasons f= or a server to have a default
> configuration which allows connections from any source IP address.

I think this text still doesn't address my point. The point is that ser= vers
may support both this specification and certificates. In this case
they should be able to only filter out IP addresses for those clients,
which are connecting with TLS-PSK and should be configurable
to allow any IP address for clients wishing to use certificates.

How about:

A server supporting this specification MUST be configurable with a set of &= quot;allowed" network ranges from
which clients wishing to use TLS-PSK are permitted to connect.=C2=A0 Any co= nnection from outside of the allowed range(s) MUST be
rejected before any PSK identity is checked.=C2=A0 It is RECOMMENDED that s= ervers support IP address
filtering even when TLS-PSK is not used.=C2=A0 There are few reasons for a = server to have a default
configuration which allows connections from any source IP address.

(MUST filter for TLS-PSK and RECOMMENDED for other cases).
=

With TLS 1.3 a server can choose to not do PSK authenti= cation and continue the handshake with certificate authentication. If this = is desired, then 'Any connection from outside of the allowed range(s) M= UST be rejected' wouldn't work if certificate authentication for th= e non-PSK address range is supported. Or if 'rejected' in this cont= ext simply means that PSK is not used, then a clarification would be useful= .

Should the text say that TLS-PSK must not be use= d and server must either do continue with server certificate authentication= or reject the connection completely?

Here's w= hat server can do with TLS 1.3 when using OpenSSL:
=C2=A0
When an attempt to use PSK i= s detected by the server, a callback function is called. The callback can:<= /div>
1. Return success and provide a PSK for PSK authentication
<= div>2. Return success but provide no PSK and authentication can continue *<= /div>
3. Reject failure to terminate the handshake

=
* If the server has configuration for server certificate authenticatio= n, then handshake continues with certificate. The server can also be config= ured without certificates and in this case the handshake is terminated beca= use it can't continue. I observed this while working on implementing th= is draft.

= --
Heikki Vatiainenhvn@radiato= rsoftware.com
--0000000000006a5d3f0609283871--