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

[Heikki Vatiainen <[e-mail]>]

On Thu, 2 Nov 2023 at 09:44, Valery Smyslov <[e-mail]> 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
[e-mail]