Hi Nathan, For IOT-2428 with OCClient and OCServer I tried to go through ownership transfer using ProvisioningClient however I received error 21 (OC_STACK_INVALID_QUERY). Why would we receive this error code? To me this error code feels like the request was wrong and not that there is an issue getting access.
OCClient and OCServer do not have a JSON/.dat file combo to specify so it is left up to the stack to generate the .dat at the initial runtime. Shouldn't this generated .dat file be able to go through ownership transfer? If not then I think JSON/.dat files need to be added so that it does work. I agree that ProvisioningClient does work with sampleserver_randompin and I haven't seen any problems lately. In this case though the issue is with OCClient and OCServer which have a much richer set of functionality then sampleserver_randompin. My understanding was that these were the main samples that we were recommending to developers to look at. If that is the case and they don't work with security then that is a major issue. However there are so many different samples so I might have misunderstood which samples we should be using. Thanks, Alex From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Heldt-Sheller, Nathan Sent: Friday, July 14, 2017 1:08 PM To: Mats Wichmann <m...@wichmann.us>; iotivity-dev@lists.iotivity.org Subject: Re: [dev] many IoTivity samples broken with security 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: iotivity-dev-boun...@lists.iotivity.org<mailto:iotivity-dev-boun...@lists.iotivity.org> [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Mats Wichmann Sent: Friday, July 14, 2017 12:57 PM To: iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> 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 iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.iotivity.org%2Fmailman%2Flistinfo%2Fiotivity-dev&data=02%7C01%7Calexke%40microsoft.com%7C5df243d52b6245f131e008d4caf41040%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636356597009622977&sdata=DOVEXI4zUiEprafTIcDbH9WgfXPL9YJMjvFdj1FUuaQ%3D&reserved=0>
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
