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

[Valery Smyslov <[e-mail]>]

Hi Heikki,

 

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

 

            My understanding is that “MUST be rejected” here applies to PSK cases only.

            If the server falls back to certificates, then “RECOMMENDED” below works.

            Perhaps this should be clearer.

 

            Regards,

            Valery.

 

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] <mailto:[e-mail]>