Hi Omar, Mats,
Security has been enabled by default for some time now... if a sample isn't
working, but it was working in 1.2, likely the .dat file needs to be updated to
conform to OCF 1.0.
Security isn't "broken"; basic functions have been working for some time and
are largely unchanged. The issues we are actively working to fix (see gerrit
and JIRA P1 "security" tagged issues to observe daily activity) are with how
the CTT uses more advanced interfaces that changed in OCF 1.0, or were never
tested in OIC 1.1.
So "turning it off" (which is basically compiling out a necessary part of the
code base) is not really an option unless you're just trying to experiment, and
may only break things that work with security on. The main reason this was
discussed for PF13 was to try to get some more CTT Test Cases to run, while
waiting to fix some Security-related bugs that were blocking the TCs from
running. This doesn't mean the stack isn't working with security on... see
below for test apps I ran that work just fine, and exercise much of the
functions that those bugs claim is broken.
Speaking of the bugs, I looked at the two bugs you highlighted (2428 and 2429)
and it appears there is some misunderstanding going on with these two bugs.
For 2429, please understand Client and Server *must* be paired ("onboarded")
and configured in order to communicate, just like a Bluetooth headset and a
phone. So in the case described in 2429, it appears the Server and Client
aren't "paired" and thus we actually would expect the requests to be denied.
Unless the Server has been configured to allow a request (which is typically
part of onboarding), it should be denied. Turning off security is one way to
bypass the expected behavior, sure, but that is actually *breaking* the
applications, by causing them to function outside of the Specified behavior.
So (again, unless the Server has been correctly configured to allow access by
the Client) the Security-enabled version is functioning correctly, and the
security disabled version is broken (functioning incorrectly).
In order to get the Client's requests to be granted:
1. The Server must be in "Ready for Normal Operation" state (i.e.
Server has been onboarded, or is using a pre-onboarded .dat file)
2. The Server's .dat file (CBOR-encoded .json file) must contain a
credential (such as a Pre-Shared Key) that matches the Client's identity
(UUID), in order to make a secure connection between the two
3. The Server must have an Access Control Entry (ACE) in the Access
Control List (ACL) that grants the request being made
These three aspects will not be true unless a) the Server is onboarded and
configured by an Onboarding Tool or b) you use pre-configured .dat files that
have already been effectively onboarded.
For an example of a pair of pre-onboarded .dat files that work together, please
see the
/iotivity/out/linux/x86_64/debug/resource/csdk/stack/samples/linux/secure
directory, and run:
$ ./ocserverbasicops |& tee server.log
And
$ ./occlientbasicops -t 2 |& tee client.log
I just did this, on Linux, and it shows things working as expected (requests
that should be allowed are allowed, such as discovery, GET to /oic/res, PUT to
/a/led, etc.). Things that should not be allowed (because there's not an ACE
that allows it) are denied, again as expected.
You can refer to the .json and .dat files used by these two applications to use
as a reference for your application's .json and .dat files (although of course
if your app hosts different Resources, it will need different ACEs). It may be
as simple as fixing the .json to conform to OCF 1.0, and re-encoding to CBOR.
And, for 2428, the provisioningclient application can only onboard a Server
Device if it has not already been onboarded by another Client. So again, if
this Server is already onboarded, then the provisioningclient *should* fail to
onboard it. I just tested the onboarding steps with a Server that is in "out
of box" (Ready for Ownership Transfer) and it worked fine. If you'd like to
try yourself, here are the steps to do that:
1. $ cd <out>/resource/csdk/security/provisioning/sample
2. $ ./sampleserver_justworks (optionally, "$./sampleserver_justworks |&
tee ss-jw.log" to capture output for later study)
3. <open a second console in same dir>
4. $ ./provisioningclient (using | tee not suggested as it tends to make
menu unusable, but once the process is memorized, you can then use | tee to
capture client-side logs)
5. at provisioningclient app menu, choose "10" <enter>
6. after discovery completes, one device should appear in "un-owned" list
and the menu is re-displayed
7. at provisioningclient app menu, choose "20" <enter>
8. after doing JustWorks OTM completes and the menu is re-displayed
9. at provisioningclient app menu, choose "10" <enter>
10. after discovery, same deviceuuid as step 6. should appear but now in
"owned" device list
Hopefully this helps... I think there's a lot of misunderstanding around what
is required to have a Client and Server function together. There is a lot of
documentation on the IoTivity wiki, and it covers everything I've said above,
but it certainly needs to be cleaned up and the most relevant parts highlighted
(something OSWG is actively working on).
Thanks,
Nathan
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Mats Wichmann
Sent: Friday, July 14, 2017 12:57 PM
To: [email protected]
Subject: Re: [dev] many IoTivity samples broken with security
On 07/14/2017 12:47 PM, Omar Maabreh via iotivity-dev wrote:
> Greetings,
>
> Many of the common samples like OCClient, OCServer, ProvisioningClient, etc.
> are no longer working with security turned on.
> Several people have asked about it, and I know some developers have been
> hunting for good builds where some of the stuff was working so that they can
> get unblocked. There has even been mention of turning security off for the
> next plugfest.
>
> All of this is pretty unhealthy as it is a tax on developers' time when
> working on features and generally bad for the ecosystem.
> I wanted to see if fixing some of the security issues could be prioritized,
> and we could come up with a plan for when we could get to a healthy state in
> IoTivity.
Thanks for filing the bugs.
Sadly, after a brief surge of enthusiasm after we talked about the problem
here, it looks like Jira tickets are back to getting virtually no attention
(the exception being when people file a bug to document something they're
intending to work on / fix themselves).
Meanwhile, I thought the samples had all gotten a fairly recent round of
attention for the secured builds after some changes in technology rendered most
of them broken. Disappointing to hear they may still (or
"again") be broken. I would echo your hope that they could get another priority
look.
_______________________________________________
iotivity-dev mailing list
[email protected]<mailto:[email protected]>
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
_______________________________________________
iotivity-dev mailing list
[email protected]
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
