It is not possibly to have non authenticated clients about californium.scandium HOT 9 CLOSED

Hi @nikosft,

I am not sure if I get your point correctly. The checks in the build() method currently make sure that a DTLSConnector run as a DTLS server can be authenticated either based on a pre-shared key or based on a public key. For this, the flag clientAuthenticationRequired has no impact as the server is always authenticated in a DTLS handshake (at least when using one of the supported cipher suites).
If you only want to use the DTLSConnector as a client in a DTLS connection then you are probably right, i.e. in this case you would not necessarily need a key pair if you use TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 and the server (to which you want to connect) does not require the client to authenticate. However, this seems reasonable only in a scenario where you control both client and server. Do you have a suggestion, how this could be reflected in the Builder?

from californium.scandium.

Hi sophokles73,

The build() method does not check whether DTLSConnector runs as a client or a server. Therefore, even if somebody does not want authenticate the client, he has to provide either a PSK store or a public/private key pair (at the client side) in order for build() to succeed. I believe that the build() method should execute the for loop at line 557 only for servers. Finally, I have the impression that, generally, client authentication is rarely used.

from californium.scandium.

I think you are mistaken in assuming that client authentication is rarely used but indeed is/will be the default for most IoT applications. Anyways, even if you plan to only run the DTLSConnector as a client and support a PSK based key exchange, you will still need to set a PSK Store since the PSK based cipher suites always require the client to provide the secret key in the (mandatory) CLIENT_KEY_EXCHANGE message (see RFC 4279, section 2 for details).
If you are running a server then you will definitely need to set a private/public key pair (if you want to support an ECDSA based key exchange) or a PSK store (if you want to support a PSK based key exchange). This is encessary regardless of whether you want to authenticate a client or not. As indicated above, in PSK based key exchanges, client authentication is implicit and thus not optional. The ECDHE_ECDSA based cipher suites require the server to provide a a DSA capable public key as part of the handshake ...

from californium.scandium.

Hi,
The scenario is TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 without client authentication. Line 565 DtlsConnectorConfig.java forces the generation of keys for the client which is unnecessary. As a proof of concept, comment out lines 565 to 575, set clientAuthenticationRequired to false in server and run an example without creating keys for the client. I will work as expected.

As far as PSK is concerned you are right.

from californium.scandium.

I see. I could imagine introducing a flag clientOnly to the Builder which you could use to indicate that the resulting DTLSConnector should only work as a client in any DTLS connection. In this case it would simply ignore any incoming CLIENT_HELLO messages. What do you think?

from californium.scandium.

May be a flag 'isClient' and also allow client code to set 'setClientAuthenticationRequired()' then at line 565 of DtlsConnectorConfig.java after the case statement add something like:

At least this worked for me

from californium.scandium.

I have added support for configuring an anonymous, client-only DTLSConnector to DtlsConnectorConfig.Builder in latest commit.

from californium.scandium.

@nikosft,

does this work for you? If so, could you please close the issue?

from californium.scandium.

Yes like a charm

from californium.scandium.