Allow using trust anchor in certificate mode

[mcocak]

LwM2M 1.0.2 only allows using the server's certificate directly which is currently implemented in Leshan, as stated in Resource 4 Server Public Key of Security object:

LwM2M 1.0.2:

Stores the LwM2M Server’s or LwM2M
Bootstrap-Server’s Certificate (Certificate
mode), public key (RPK mode). The
format is defined in Section E.1.1.

However, this was changed in LwM2M 1.1 where it is also added to use the trust anchor, not only server's certificate. Same Resource 4 Server Public Key of Security object:

LwM2M 1.1:

Stores the LwM2M Server's, respectively LwM2M Bootstrap-Server's, certificate, public key (RPK mode) or trust anchor. The Certificate Mode Resource determines the content of this resource.

Testing leshan-client with certificate mode and providing CA certificate of the server as input in -ccert, DTLS handshake is completed successfully but DTLSConnector drops the first CoAP message since the certificate I provide is not exactly the same as the certificate the server provides.

2020-09-16 19:22:08,368 INFO drops - DTLSConnector (DTLS-0.0.0.0:64254) drops 52 bytes outgoing, [CN=Great Bootstrap CA] != [x509 [CN=bootstrap.greatbootstrap.com,OU=Great cloud,O=Awesome Ltd,L=Hawaii,ST=Honolulu,C=US],TLS_ECDHE_ECDSA_WITH_AES_128_CCM]

Server's certificate is derived from the CA certificate so Leshan client (Leshan v2.0) should be trusting the server according to LwM2M 1.1.

[sbernard31]

Testing leshan-client with certificate mode and providing CA certificate of the server as input in -ccert,

You mean -scert ?

You're correct regarding : https://tools.ietf.org/html/rfc6698#section-2.1.1
LWM2M v1.0.x only supports 3 - domain-issued certificate usage

For LWM2M v1.1.x all certificate usages are supported.
Client should use Server Public Key resource (/0/?/4 which contain server certificate) depending on Certificate Usage resource (0/?/15).

The Certificate Usage Resource specifies the semantic of the certificate or raw public key stored in the Server Public Key Resource, which is used to match the certificate presented in the TLS/DTLS handshake. The currently defined values are 0 for "CA constraint", 1 for "service certificate constraint", 2 for "trust anchor assertion", and 3 for "domain-issued certificate". When this resource is absent, value (3) for domain issued certificate mode is assumed. More details about the semantic of each value can be found in the security consideration section of the LwM2M specification.
(source : §E1-LwM2M-Object-LwM2M-Security)

So this is clearly something we need to implement for 2.0.0. (but not yet available :/)
@mcocak do you need this at short term ? (for what purpose testing with client demo or implemented tests or implemented "real device" ?)

@boaks do you think it makes sense to create 4 new CertificateVerifier in addition of the current default one in californium/scandium. I mean one for each usage :

• CaConstraintCertificateVerifier
• ServiceCertificateConstraintCertificateVerifier
• TrustAnchorAssertionCertifcateVerifier
• DdomainIssuedCertificateCertificateVerifier

Or should it be only in Leshan ?

@dachaac is it something you need (direct or indirectly) to implement for EST ?

[boaks]

I guess, I have to read the LwM2M TS to see the differences :-).

Californium currently verifies a CertifcatePath based on the trusted certificates. That may be any certificate of the path or the issuer's of the last certificate of the path. The processing of a DomainIssuedCertificate was currently fixed in CertPathUtil (using truncateCertificatePath with true) .

I'm not sure, if it is important to explicit select the variant.
To start with, maybe selecting the certificate to trust will do it.

[sbernard31]

@boaks, I think you only need the resource description in my previous comment and the https://tools.ietf.org/html/rfc6698#section-2.1.1. The idea is to define the server certificate validation behavior at client side.

I'm not sure, if it is important to explicit select the variant.

For LWM2M, I think it make sense and as this is not specific LWM2M concept. I think this should maybe better placed in Scandium.

But we can implement it in Leshan and you will see if this makes sense to move it to Scandium later.

[dachaac]

I have code already for this in:
https://github.com/dachaac/leshan/commits/est-support

Needs the Unsigned Integer support (#880) and then we can start picking up those changes.

[sbernard31]

I have code already for this

Good news, I will try to make #880 forward.

[boaks]

(I'm not a fan of that "micro-service-stuff, but ...)

Just as remark:

With Californium 2.5.0 the CertificateVerifier will be deprecated and replaced in the future by the NewAdvancedCertificateVerifier. Check StaticNewAdvancedCertificateVerifier.Builder for the upcoming API.

[sbernard31]

(I'm not a fan of that "micro-service-stuff, but ...)

(Ok so probably added only in Leshan.)

With Californium 2.5.0 the CertificateVerifier will be deprecated and replaced in the future by the NewAdvancedCertificateVerifier.

Ok we will adapt the code when we will integrate cf-2.5. (thx for letting us know)

[boaks]

(I'm not a fan of that "micro-service-stuff, but ...)

That means: the API changes caused by the async certificate verifier may not really "pay off" for everybody. It's not too hard to migrate, but I'm not sure, how many will use the async feature, except of hono.

[sbernard31]

That means: the API changes caused by the async certificate verifier may not really "pay off" for everybody. It's not too hard to migrate, but I'm not sure, how many will use the async feature, except of hono.

Oh I didn't get this at all. 😅
I will let you know if we use it at some point.

[sbernard31]

Needs the Unsigned Integer support (#880) and then we can start picking up those changes.

@dachaac #880 is now integrated in master.

[dachaac]

@sbernard31 rebased my https://github.com/dachaac/leshan/commits/est-support branch with that all.

It has couple of WIP commits in top -- but in theory one could pick up some commits before that.

I would say all commits before EST stuff is something that could be considered eg.:

X509CertUtil: Add new helper class for using X.509 certificates
...
CaliforniumEndpointsManager: Add support to verify server identity in certificate verifier

also:

LeshanBootstrapServerDemo: Add support to load trust store from Java trust store
SecurityUtil: Add helper asX509Certificates

could be taken.

I can tune it a bit just tell what kind of PR would you like to have ;)

I would say you need a lot of those to get to good level :)

[sbernard31]

Let's start by certificate usage as this is requested by @mcocak :-)

I can tune it a bit just tell what kind of PR would you like to have ;)

We will discuss of this in PR(s) but I would rather go for one dedicated CertificateVerifier(in dedicated class) by certificate usage unless there is a good reason to keep on the logic in 1 class.

[boaks]

Please, ensure to cover these modes with unit tests ;-).
I've tried to complete my unit-tests for the CertPathUtil right now in the californium's master.

If the intention is to trust the certificate of the node itself (even if this is not a self-signed), then in my experience truncateCertificatePath must be true, because you can't pass the full certificate path to java's CertPathValidator. (Note: I recently fixed the implementation to work proper for that mode.)
The same is true, if you want to trust a "intermediate" certificate in the middle of the certificate path.
Both, at least using java-7 and java-8.

See my unit-tests:

CertPathUtilTest
testServerCertificateValidationWithIntermediateTrustFails
testServerCertificateTruncatingValidationWithIntermediateTrust
testServerCertificateValidationWithSelfTrustFails
testServerCertificateTruncatingValidationWithSelfTrust

If you get different experience, I'm very interested to adapt my code as well.

[sbernard31]

@mcocak, master contains a first support of certificate usage at Leshan client side. (not yet in leshan-client-demo)
(You can have a look at #923 for more details)

Feedback is welcome.

[sbernard31]

Since 2.0.0-M3 there is a functional certificate usage support in library and demos.