Certificate usage support

[dachaac]

LWM2M 1.1 brings certificate usage support.

In order for certificate usage support to be more practical these commits also add other features.

Certificate chain support is being added for client to allow supplying certificate chain with intermediate CA's. Problem with LWM2M is that it can support in X.509 mode only one level CA setup (unless server's trust store has all needed intermediates where only Root CA's should be in trust stores). In EST mode certificate delivery is different and can easily support intermediate CA setups. X.509 problem comes from Security Objects certificate field is X.509 certificate encoded as DER. If it would have been PKCS#7 certificate bundle encoded as DER then it would have worked better.

Note: It is industry best practice to have Root CA in offline environment and Intermediate CA in online environment (like what would be used by EST server or by device manufacturing flows).

Note: Actual EST support is to be coming in future and is not part of these commits.

Note: redis support has not really been tested -- it has just been adapted with match changes.

These commits fix server certificate checking to support subjectAlternativeNames which is today's requirement for TLS Server Certificates (vs. using Subject DN's CN field). At the same time support is added for DNS, IPv4 and IPv6 addresses for TLS Server Certificates.

Fixes: #893
Relates to: #859

[dachaac]

Note: I am aware that there are certificate usage test cases missing that should be there. Will be added. But lets get the review otherwise on going not to delay it.

[boaks]

@dachaac

I will check, if the tests cover my experienced issues developing the CertPathUtil in Californium.

[boaks]

The tests in org.eclipse.leshan.integration.tests.SecurityTest seems to use SecureIntegrationTestHelper.createServerWithX509Cert, which creates servers using one certificate as path/chain.
I can't find test, where e.g. a server certificate path with 3 certificates is used, and the middle one is trusted.
Nor a test, where a path/chain with more than one certificate is used and the peer's certificate (first) is trusted (that would require Californium 2.5.0, or a additional 2.4.2 bugfix release).
Also the clients seems to use only DOMAIN_ISSUER_CERTIFICATE.

Maybe, I have overseen some tests somewhere else. If so, please point me to.

[dachaac]

@boaks as mentioned the test cases are coming soon :)

[dachaac]

• Added Web UI for configuring certificate usage.
• Fixed bug in SNI stuff.
• Fixed bug in Unsigned Integer's ULong transition (vs. my previous hack).
• Still missing unit tests for certificate usage

[boaks]

Uups, my bad ;-(.
I misunderstood your comment.

[dachaac]

@boaks sorry if there was confusion about it.

I have now written some more tests but I faced a bit weird DTLS handshake problem where it gets stuck. You might have the expertise to know where the problem is. I didn't yet spot anything that things would be forbidden by my certificate usage rules or so -- kinda feels some unrelated thing just that happens to be triggered.

I didn't push them yet in this branch but they are on top of my est-support branch:
https://github.com/dachaac/leshan/tree/est-support

In SecurityTests.registered_device_with_x509cert_to_server_with_x509cert_rootca_certificate_usage_ca_intca_given

I added comment about the problem:

        // Fails for some reason:
        // 6794	4.654513916	127.0.0.1	127.0.0.1	DTLS	169	Client Hello
        // 6817	4.659159774	127.0.0.1	127.0.0.1	DTLSv1.2	102	Hello Verify Request
        // 6823	4.660218141	127.0.0.1	127.0.0.1	DTLSv1.2	201	Client Hello
        // 6935	4.672405989	127.0.0.1	127.0.0.1	DTLSv1.2	1329	Server Hello, Certificate, Server Key Exchange, Certificate Request, Server Hello Done
        // 7062	4.715745042	127.0.0.1	127.0.0.1	DTLSv1.2	768	Certificate, Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted Handshake Message
        // 7071	4.722015573	127.0.0.1	127.0.0.1	DTLSv1.2	117	Change Cipher Spec, Encrypted Handshake Message
        // <connection sequence gets stuck here>

Another problem seems to be what can be debugged with same test case is that if you have breakpoint in CaliforniumEndpointsManager :: verifyCertificate and observe:

certPath = CertPathUtil.validateCertificatePath(false, messageChain, trustedCertificates);

certPath is missing root CA at the beginning and that is part of trustedCertificates and this will be a problem in later phases when we would need to observe the full chain. For CoAP-EST support I had to make some glue code in DefaultRegistrationEngine::estExtractClientCertificateChain() that glues CA certificates and issued certificate to client certificate chain in order for client to send proper chain when connecting to LWM2M server. (That still needs a bit updates when fine tuning the code.).

[dachaac]

I am considering dropping server side SNI enablements as that causes empty name to be sent from server. Fixing that to have some name seems to be a bit larger job and I don't think it really brings so much gains. Client side I believe is correct and should be there in case client is connecting to server that has a need for SNI.

[dachaac]

Problem is in Leshan side -- exactly on Lwm2mEndpointContextMatcher.matchPrincipals().

I added debug:

    protected boolean matchPrincipals(Principal requestedPrincipal, Principal availablePrincipal) {
        System.out.println(this.getClass().toString() + ".matchPrincipals() req=" + requestedPrincipal + ", avail=" + availablePrincipal);
        System.out.flush();

and I do get frollowing output:

class org.eclipse.leshan.core.californium.Lwm2mEndpointContextMatcher.matchPrincipals() req=CN=Leshan intermediate CA, avail=x509 [CN=Server signed with Intermediate CA]

And based on that implementation there -- there is no match and thus nothing is being sent.

requestedPrincipal value here is what was in serverPublicKey field encoded (and in this test case it is intermediate CA) -- kinda correct but kinda wrong in this spot. And available was received from server which is of course correct and in that CertPath one can see also intermediate.

Now the question here is how should this be handled in here correctly.

Should we have custom matcher that also has certificate usage policy attached. In theory one probably should match the DTLS connection session here and make lookup based on that one? But then again if some other server from that CA would be sending with same port/address match would be invalid.

One possibility could be that once we have done the certificate usage policy part and then we construct CertPath again and then we attach that for particular connection so then end certificate match could be done.

@boaks + @sbernard31 How do you think this should be working?

[boaks]

I guess leshan uses parts (DN) of the "server's certificate" from the security object as EndpointContext. Though that certificate is now the CA, it doesn't work, because Californium fills the received server certificate path in that context to match. Unfortunately, I'm not used to leshan's EndpointContext management. If you want to continue and postpone the fix until @sbernard31 has time, then just ignore the test in the EndpointContextMatcher and return true.

[dachaac]

Missing root CA in CertPath I could augment by filling missing CA's from trust store by changing it to use AdvancedCertificateVerifier. I am wondering if the right place for that fix would actually be CertPathUtil.validateCertificatePath().

Moved the code to class DefaultLeshanCertificateVerified so that it can have a bit of state too.

If I return true on there my tests passes but I am not sure if that is the correct thing to do. As result there is now one failing test case:
[ERROR] SecurityTest.dont_sent_request_if_identity_change:157 send must failed

Updated est-support branch with that test code. I also added some extra debugs in californium to debug it a bit more but I suppose those are not needed now that point is kinda identified.

Problem seems to be related to fact that when message is being prepared for sending we do not yet know anything about peer (eg. the server) thus only information there is intermediate CA. I believe this is kinda a wrong implementation that is in place as there is already related connection that actually knows the peer identity but then again I might be missing some point.

[boaks]

The EndpointContext is a collection of data, representing the communication context. It contains, the ip-address, SNI (if used), the authorized peer (in case of x509 the verified certificate path), and some session data (e.g. ID and cipher suite). It's up to the matcher, which contexts are accepted for an message exchange. Therefore the matcher select the relevant data from the context for it's specific situation.
In that case, it seems that leshan constructs the peer's identity out of the stored certificate, which works, if the server's certificate itself is stored, but not, if a CA's certificate is stored.
Let's wait on Simon's answer, I strongly guess, that leshan will adapt the used EndpointContext or the EndpointContextMatcher on the leshan side.

[sbernard31]

About, the matching principal issue :

Leshan client use ServerIdentity as class to identify a server.
Currently for x509 this class uses internally x509commnName to identify a server.

This commonName is extracted from Security Object (0). (see CaliforniumEndpointsManager.createEndpoint(ServerInfo))
As we only used "domain-named issue" that made sense, but now we should change it.

The question is : what currently identified the server ? Maybe the URL which should available in Security Object too and which should be retrieve in available principal too. (SNI is also a potential candidate when it used.)

About the PR itself:
I was expecting a more step by step approach, maybe like :

1. add it to client + unit tests
2. add to leshan client demo
3. add to bs server + unit tests (maybe too soon because of Refactor BootstrapConfigStore to use a list of "request" #883)
4. add to bs server demo (same as above)
5. add support of SNI (need probably some discussion at least to explain the idea and why this will be used with Leshan)

And of course there is this critical issue about certificate chain raised here : OpenMobileAlliance/OMA_LwM2M_for_Developers#502

[dachaac]

About Matching the principal.

I may be missing something here so feel free to correct me.

Now in client side this is rather simple in a way. It has know direction where to connect. It knows target address and port and can match the communication based on that one. This seems to be happening already like this and I believe Californium is doing this.

In server side when client is connecting there we kinda get DTLS session done first and we know the identity of the client right a way. And then we can continue matching the address + port and then lookup which connection it is. I believe this is already done in Californium.

If you have NAT in between in theory if the client opens the connection then connection tracking is happening in NAT service and in theory server nor client need to know about it.

During handshaking phase client wants to verify that server is what it is expected to be. And server wants to verify that connecting client identity is verified and known. This does the mutual authentication part. After this as long as there is connection tracking we should be fine? DTLS makes it even more less likely that someone could interfere with injected frames as session is encrypted and MACed.

During DTLS handshake with X509 there is certificate verify phase where we have the CertificateVerifier and after that we start to know what the other party is. So in the end of handshake we know the real identity of the other part. And later Californium should be handling connection tracking and DTLS stuff and Leshan shouldn't need to care anymore.

Now what happens in Leshan Client. It is preparing the endpoint and thus gets DTLS socket created for the connection. It does not know yet full details of the server but it makes best guess based on URI and with details in Security Object. It prepares LWM2M Registration message that gets sent thru the end point. And as there is not yet DTLS handshake done it starts to perform that. Now that there is this self censorship as it is not sure that destination is correct for message it drops the registration frame and it is never sent and thus not received. This is where I do not understand why this is happening on the send operation as it should only be concern for the peer that the received frame is something that is expected. On receive with DTLS we get identity information from the context which is always correct to operate on (and with full chain re-constructed we can do all checks with it). Californium should be handling the connection tracking part so Leshan should not have a need to care about that. In server side we just need to have state tracking done so that different messages like registration can keep the information like end point name in state and necessary association for device inventory or so.

If you set the breakpoint on this context matcher in Leshan side you can observe that the context has been matched already before the method.

I have been thinking that perhaps the Security object should be disconnected from actual connection logic. When doing initial connection we do not kinda even have security object until bootstrap server indicates one. With EST it is even more disconnected and certificates are out-of-bound of Security object. And then we have this Certificate Usage business which mixes it even more.

[boaks]

Because the ideas may vary, Californium just offers all the information, including the peer's identity and the dtls session, to delegate that decision to the next layer. One way to use that is to keep the the EndpointContext received in the MessageObserver.onContextEstablished(EndpointContext endpointContext) and use one of Californium's EndpointContextMatcher. Using custom-endpoint-context-matcher is also a way to go. If that custom implementation is based on an assumption (stored server's certificate, no CA), which is now changing, just change that custom implementation.

[boaks]

The matcher is not about authenticate the other peer, that done in the handshake.
Lookup that context "later" using the address will cause the same issues, as a rehandshake does for TLS: the lookup may get a newer identity then the record was received with. For TCP that's hard to solve, for UDP we decided just to add that EndpointContextto each record, so no "later" lookup is needed.
And using the EndpointContext is not limited to check only the identity (that requires unique identities, lwm2m does so, other may not), it may also be used to check the session for request-response matching as RFC7252 - 9.1.2. Request/Response Layer (using DTLS), if that is considered to be useful in your use-case.
For sending a message, that matching is use to prevent sending messages accidentally to the wrong peer. Assuming to communicate with peer A on address 1, would leak data, if a peer B would have established a connection also on address 1. With that matching, that could be prevented.

[sbernard31]

FMPOV,

DTLS layer is responsible to authenticate the foreign peer.
For LWM2M, from this authentication we are able to extract something as an identifier. Psk identity for PSK, public key for RPK and until now CN for x509 (for x509 this could be not good enough and could change in the future)

At LWM2M level we only handle this identity, we don't care about lower layer details.
So when we receive or send a message from a given peer we always verify that we are talking the to expected peer. (identities must match)
In practice, this is done thanks to EndpointContext and EndpointContextMatcher.

At Leshan level we don't care if DTLS connection or DTLS session changed we just want to be sure that identity don't change.
(even if this is a bit out of specification : here is a little part of explanation)

You could ask : but how identity could change ?
When you are using 1 socket for several foreign peers, same address IP/port should be used by several foreign peers and sometime you could talk to an unexpected peer by "stealing" a previously used one. (I can give you concrete example if you need)

This is the case for Leshan Server and Bootstrap Server. (1 socket for n client)
This was also true for Leshan Client (1 socket for n server) but following @boaks recommendation (#450) we changed it for 1 socket for 1 server.

So in case of 1 socket for 1 foreign peer, if DTLSConnector is restrictive enough to ensure that only the expected peer will connect to this endpoint. (and I think we can do that, this is maybe already the case) we could relax endpoint context matching at client side only. This is maybe simpler. 🤔

I have been thinking that perhaps the Security object should be disconnected from actual connection logic. When doing initial connection we do not kinda even have security object until bootstrap server indicates one.

I think it's not so true as before server initiated bootstrap there is at least factory bootstrap which contains setting with default credentials store in Security Object.

With EST it is even more disconnected and certificates are out-of-bound of Security object. And then we have this Certificate Usage business which mixes it even more.

For EST I don't know enough for now.

[dachaac]

Changes:

• Dropped SNI stuff completely from the PR
• Implemented more tests
• Added new DefaultLeshanCertificateVerifier class to aid in certificate verification and expanding of CertPath
• Added new Lwm2mClientEndpointContextMatcher class to differentiate client vs server needs
• All tests pass now
• Re-ordered commits so that they are in order of the need

[dachaac]

@boaks now certificate usage test suite is "complete". Second eye checking them would be good here.

[dachaac]

@boaks & @sbernard31 created a new Lwm2mClientEndpointContextMatcher that still does the verification but in client case it accepts also "server" certificate to be in any part of the chain.

[dachaac]

@sbernard31 Now this should have all commits that are needed.

We can split it to one or more PR's but order is about there now.

Change set starts with fixing CN handling in tests as that is integral part of the later changes which make it even more enforced that those names are correct.

About trust store change.

In Java usage of trust store and key stores is the norm. Also californium has the support out-of-the-box so why not utilize it.

This is actually quite good as we may want to utilize key store with EST too at later stages. But that we can look at later.

As client is missing the trust store support so idea was to modify LeshanServerDemo first and then just copy that implementation around. It is latter also copied to LeshanBootstrapServerDemo but that is only visible in est-support branch and not here as it is not needed in here.

"LeshanClientDemo: Add trust store support." could be split in two to have changes for LeshanClientDemo in own commits if that is what you were looking? LeshanClientDemo part can also be bubbled up.

"LeshanClientDemo: Add support for client certificate chain" can also be bubbled up after tests if you want that.

"LeshanServerDemo: Add support to load trust store from Java trust store" can also be bubbled up after tests if you want that.

"CertificateUsage: Add CertificateUsage support" could also be split to extract LeshanClientDemo changes to own commit and bubble it up after tests if you want that.

Then the rest of changes till certificate usage integration tests are just incrementally adding new features so that integration tests can pass.

[boaks]

registered_device_with_x509cert_to_server_with_x509cert_rootca_certificate_usage_taa_intca_given

* Expected outcome:
* - Client denied the connection (not pkix chainable, client trust store not in use, server not sending root CA and TAA is not root CA)

That would mean: intermediate CAs will not be allowed as trust anchor.

I'm not sure, if that is really expected. If not, see truncateCertificatePath to change it.

[sbernard31]

@dachaac Could you please push your commits 1 by 1 or by little consistent group. I let you decide what fits better. The idea is to limit the number of points addressed in the same PR AND be able to merge contribution faster in master.
Is it OK for you ?

The most disturbing part to me is about using pem instead of der encoding in /0/?/3, I will try to get answer about that from OMA.
(Even if currently I can not see any other way ... 😕 )

[sbernard31]

Thinking a bit about that certchain but for certificate usage we don't really need this right ? (I mean the pem stuff)

[sbernard31]

@dachaac maybe you should be involved in OpenMobileAlliance/OMA_LwM2M_for_Developers#502

[dachaac]

Note: some rebase mayhem may have broken the configuration UI. At least it seems to be broken in my est-support testing branch. Need to debug this more.

[dachaac]

Found the fix for webui and applied it to my est-support branch. Should not have effect for this PR.

[dachaac]

PR #905: Trust store updates

[dachaac]

Now previous commits before certificate usage stuff has been merged so I have now rebased and updated this PR a bit.

I have sliced a bit more commits so that *Demo commits are on own commits.

Now the question is do we split this more.

In order to be testable one needs to have all commits in between.

[sbernard31]

I suppose a good next step could be a PR with commits which introduce certificate usage at client side + new integration tests about that ? (without server or demo modification)

[dachaac]

I suppose a good next step could be a PR with commits which introduce certificate usage at client side + new integration tests about that ? (without server or demo modification)

Not so easy anymore ;)

But managed to slice it a bit more in PR #912.

[sbernard31]

@dachaac, I plan to release a 2.0.0-M2 version either before my vacation (at the end of the week) or maybe after (begin of January)

Do you want to integrate more certificate usage code in this release ?
Maybe I should add at least the client demo command line option ? (762bcd4 ) 🤔

[dachaac]

@dachaac, I plan to release a 2.0.0-M2 version either before my vacation (at the end of the week) or maybe after (begin of January)

Do you want to integrate more certificate usage code in this release ?
Maybe I should add at least the client demo command line option ? (762bcd4 ) 🤔

Unfortunately I have been hit with some high priority stuff :|. So my window kinda opens next week for rebasing and for such operations.

I believe it would probably be more useful to have all client config stuff and probably a good idea to have also the server side.

If you are not too rush to have extra content this week I would probably recommend just fine tuning this PR after your M2 release and when ready then integrate.

[dachaac]

Re-worked the branch on top of master.

[dachaac]

@sbernard31 now that this PR is reworked -- is there some commits that you would like to have -- there are webui stuff here too -- but I suppose you wanted those on top of new webui?

[sbernard31]

I had a quick look at this.
Except if I missed something, I feel that those 2 points are not directly linked to Certificate Usage feature :

1. The support of SNI.
2. Certchain support in Public Key or Identity resource.

They could generate more discussions and will slow down the integration of Certificate usage feature so I think this is better to move this in other PRs.
(Spoiler alert, for the last one my current understanding is that this is not supported neither for LWM2M 1.1 nor 1.2 so I prefer to do introduce it for now. see OpenMobileAlliance/OMA_LwM2M_for_Developers#502)

About this PR itself, I do not get the usage of CertificateUsage in SecurityInfo 🤔 ? (commit
a13b5f1)

there are webui stuff here too -- but I suppose you wanted those on top of new webui?

I guess this is too soon as the new UI is for now only available for leshan-server-demo* and your changes are about leshan-bsserver-demo*. (I need to work on it too 😬)
We can start with the old demo only (as this is already coded)

[sbernard31]

(If you want I can cherry pick the code from this PR and create a new one)

[dachaac]

(If you want I can cherry pick the code from this PR and create a new one)

#983

[dachaac]

2. Certchain support in Public Key or Identity resource.

They could generate more discussions and will slow down the integration of Certificate usage feature so I think this is better to move this in other PRs.
(Spoiler alert, for the last one my current understanding is that this is not supported neither for LWM2M 1.1 nor 1.2 so I prefer to do introduce it for now. see OpenMobileAlliance/OMA_LwM2M_for_Developers#502)

I believe the point made in there was that EST provides the client certificate chain out-of-band of LWM2M protocol itself and thus not subject to any problems.

And also initial deployment with client certificate chain is not subject to any problem.

The problem that Leshan is that those are quite tied up. Eg. in order to support it one either need to use existing in memory storage of same structure (what has been done now) or to have this information in another structure/class and if updates comes thru EST then that gets updated and if they come thru Security object then they get updated too. And then this another structure is used when making connections.

We have already verified with the commercial offering that the concept works.

[dachaac]

About this PR itself, I do not get the usage of CertificateUsage in SecurityInfo ? (commit
a13b5f1)

This we can continue in the new PR :)

[sbernard31]

with #991 I'm not sure if we can close this one ? 🤔

[sbernard31]

I close this PR as most must be integrated in #991.
I will reference this PR in #859 as some part is not integrated :

• The support of SNI.
• Certchain support in Public Key or Identity resource.

@dachaac please to not hesitate to reopen if needed.