Add an easy to know if foregin peer is using PSK in TlsServer.getCredentials()

[sbernard31]

In my case I have a DTLS server (using bouncy castle low level API), which need to support PSK, RPK and X509.

Currently,

• when client want to use RPK or X509, TlsServer.getCredentials() should return BcDefaultTlsCredentialedSigner.
• When client want to use PSK then TlsServer.getCredentials() should return null.

But there is no easy way to know what choose the client with current API.

KeyExchange negociation is done at :

bc-java/tls/src/main/java/org/bouncycastle/tls/DTLSServerProtocol.java

Line 189 in d858403

state.keyExchange = TlsUtils.initKeyExchangeServer(serverContext, server);

And

bc-java/tls/src/main/java/org/bouncycastle/tls/TlsUtils.java

Lines 4534 to 4589 in d858403

	private static TlsKeyExchange createKeyExchangeServer(TlsServer server, int keyExchange) throws IOException
	{
	TlsKeyExchangeFactory factory = server.getKeyExchangeFactory();
	switch (keyExchange)
	{
	case KeyExchangeAlgorithm.DH_anon:
	return factory.createDHanonKeyExchangeServer(keyExchange, server.getDHConfig());
	case KeyExchangeAlgorithm.DH_DSS:
	case KeyExchangeAlgorithm.DH_RSA:
	return factory.createDHKeyExchange(keyExchange);
	case KeyExchangeAlgorithm.DHE_DSS:
	case KeyExchangeAlgorithm.DHE_RSA:
	return factory.createDHEKeyExchangeServer(keyExchange, server.getDHConfig());
	case KeyExchangeAlgorithm.ECDH_anon:
	return factory.createECDHanonKeyExchangeServer(keyExchange, server.getECDHConfig());
	case KeyExchangeAlgorithm.ECDH_ECDSA:
	case KeyExchangeAlgorithm.ECDH_RSA:
	return factory.createECDHKeyExchange(keyExchange);
	case KeyExchangeAlgorithm.ECDHE_ECDSA:
	case KeyExchangeAlgorithm.ECDHE_RSA:
	return factory.createECDHEKeyExchangeServer(keyExchange, server.getECDHConfig());
	case KeyExchangeAlgorithm.RSA:
	return factory.createRSAKeyExchange(keyExchange);
	case KeyExchangeAlgorithm.DHE_PSK:
	return factory.createPSKKeyExchangeServer(keyExchange, server.getPSKIdentityManager(), server.getDHConfig(),
	null);
	case KeyExchangeAlgorithm.ECDHE_PSK:
	return factory.createPSKKeyExchangeServer(keyExchange, server.getPSKIdentityManager(), null, server.getECDHConfig());
	case KeyExchangeAlgorithm.PSK:
	case KeyExchangeAlgorithm.RSA_PSK:
	return factory.createPSKKeyExchangeServer(keyExchange, server.getPSKIdentityManager(), null, null);
	case KeyExchangeAlgorithm.SRP:
	case KeyExchangeAlgorithm.SRP_DSS:
	case KeyExchangeAlgorithm.SRP_RSA:
	return factory.createSRPKeyExchangeServer(keyExchange, server.getSRPLoginParameters());
	default:
	/*
	* Note: internal error here; the TlsProtocol implementation verifies that the
	* server-selected cipher suite was in the list of client-offered cipher suites, so if
	* we now can't produce an implementation, we shouldn't have offered it!
	*/
	throw new TlsFatalAlert(AlertDescription.internal_error);
	}
	}

But there is nothing store which can be reused in TlsServer.getCredentials() (Or at least I didn't find it)

For now I use this not so good alternative :
https://github.com/eclipse-leshan/leshan/blob/07d2f3e00b0dfa4bfea61e07b6cf6bf886a6519d/leshan-tl-jc-server-coaps/src/main/java/org/eclipse/leshan/transport/javacoap/server/coaps/bc/endpoint/LwM2mTlsServer.java#L113-L124

If would better if we could have the negotiated information about that in API or maybe in that case TlsServer.getCredentials() should not even be called ? (not sure about that)

[peterdettman]

Up to (D)TLS 1.2, PSK is dictated by the negotiated key exchange, so your "not so good alternative" is basically the right way to do it (except that RSA_PSK does need RSA encryption credentials if you support it). e.g. see

bc-java/tls/src/main/java/org/bouncycastle/tls/PSKTlsServer.java

Lines 50 to 68 in d858403

	public TlsCredentials getCredentials() throws IOException
	{
	int keyExchangeAlgorithm = context.getSecurityParametersHandshake().getKeyExchangeAlgorithm();
	switch (keyExchangeAlgorithm)
	{
	case KeyExchangeAlgorithm.DHE_PSK:
	case KeyExchangeAlgorithm.ECDHE_PSK:
	case KeyExchangeAlgorithm.PSK:
	return null;
	case KeyExchangeAlgorithm.RSA_PSK:
	return getRSAEncryptionCredentials();
	default:
	/* Note: internal error here; selected a key exchange we don't implement! */
	throw new TlsFatalAlert(AlertDescription.internal_error);
	}
	}

Indeed, the negotiated key exchange algorithm dictates the server credentials you need to choose in general, so a switch on KEX in this way is pretty much necessary in the general case. See DefaultTlsServer#getCredentials too. Your linked code doesn't seem to pay attention to the required signing key algorithm (required at this point but the whole process begins earlier with not supporting cipher suites that would require server credentials you don't have on hand).

Even if the KEX dictates a return of null I guess it's better to still have the call so that user code gets to do whatever it needs to at the point the server's credential needs are determined. We couldn't stop calling it now due to existing code possibly relying on it anyway.

Note that TlsServer#getPSKIdentityManager is (only) called when a key exchange is selected that will require the client to send PSK.

[sbernard31]

@peterdettman thx a lot again for clarification 🙏.

Just in case, I was not clear.
I understand that KEX is mainly negotiated via cipher suite negotiation.
I see that we already do a switch based on KeyAchangeAlgorithm to create TlsKeyExchange.

So naively, I was thinking that I will not need to do a switch again especially for PSK.

I was thinking that I could do something like : context.getSecurityParametersHandshake().usePskKeyExchangeAlgorithm();

(even ideally context.getSecurityParametersHandshake().getKeyExchangeAlgorithm().isPsk() but that would be in a world where KeyExchangeAlgorithm are not jus a int but a class or an enum)

[peterdettman]

RSA_PSK needs PSK and credentials, so merely "isPsk" is not what you need here, and you need to also know the server credentials type (DSA, ECDSA, RSA signing or RSA encryption). I'm open to suggestions that can reduce boilerplate of course, but bear in mind that all things key exchange related are already gone from TLS 1.3 (PSK there uses a different system too).

[sbernard31]

Thx I get it now.
I was not too much familiar with RSA_PSK.

I hope my questions are not too annoying.
I'm clearly not a DTLS expert maybe eventually an advanced user.

I try to provide user feedback so you could decide if there is way for enhancement.
Probably in that case, the issue was mainly that I'm not aware enough of some DTLS details.

I really appreciate your help 🙏

(Should I close the issue?)

[peterdettman]

We're open to adding improvements. I think the main issue here is finding and loading appropriate server credentials. The BCJSSE level has the usual JSSE support for key/trust managers and surrounding logic, but it is largely missing from the low-level server code (felt more keenly with DTLS where BCJSSE is not currently an option).

[sbernard31]

I think the main issue here is finding and loading appropriate server credentials.

From a beginner user point of view, when I started I didn't expect a so low level API.

I mean I was thinking that I will call a kind of builder which allow me to provide mandatory information like :

• a kind of PSK store/manager
• private key
• public key or X509 certificate.
• a truststore or certiifcate verifier.

And from that + some default value I will get a working Poc quickly.

Also I was thinking that I would be able to easily reuse some JDK classes or interfaces like (PublcKey, PrivateKey, X509Certificate, CertPath etc etc... )