Thanks Alex, I took a quick look at the logs and indeed it's a callback issue in the sample apps: the PIN OTM requires a PIN display callback. It always has been this way, since prior to 1.2, but Dan (cc'd) introduced a change to make Random PIN the default, in the case of no .dat file, which means any application that doesn't include a .dat file must implement the PIN callback and register it.
This should be something easily fixed with a quick update to the app (either introduce a .dat that support JustWorks, or update the app to implement the callback for PIN display). The application "sampleserver_randompin.cpp" in the security/provisioning/sample directory shows an example of the callback (OC_CALL) and registering it (using functions from pinoxmcommon.h). If this isn't something you're comfortable fixing, just assign the issue to me and I'll try to find time this weekend. Thanks, Nathan From: Alex Kelley [mailto:ale...@microsoft.com] Sent: Friday, July 14, 2017 2:57 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com>; Mats Wichmann <m...@wichmann.us>; iotivity-dev@lists.iotivity.org Subject: RE: [dev] many IoTivity samples broken with security Hey Nathan, I have uploaded the logs onto IOT-2428 and assigned it to Randeep. I saw the same behavior as before so it should be captured. If there are any other logs that you need please let me know. It is definitely possible that this sample might need some larger updates given all of the recent changes with security. I have never really looked into this one outside of testing so I am not as familiar with the internals. I agree though that the upper functionality shouldn't have any effect on security but we need to have a sample that can do both security operations as well as normal operations. I can't say that these are the absolute go to samples however I know that others have used them and they support a lot of functionality. If anyone can recommend a better set of samples that showcase the end to end scenario functionality I am all for using those and removing these. Thanks, Alex From: Heldt-Sheller, Nathan [mailto:nathan.heldt-shel...@intel.com] Sent: Friday, July 14, 2017 2:16 PM To: Alex Kelley <ale...@microsoft.com<mailto:ale...@microsoft.com>>; Mats Wichmann <m...@wichmann.us<mailto:m...@wichmann.us>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: RE: [dev] many IoTivity samples broken with security PS: it may be worth considering that the richer functionality of OCServer (for example) should have absolutely zero effect on onboarding... the entire onboarding process is handled by the Security Resource Manager which sits below the application layer. The application only provides the persistent storage callbacks for the SRM to use; otherwise it is uninvolved in onboarding. So perhaps there is an issue with the PS callback implementations? I am just guessing on the cause, but the point is that the onboarding process should be almost entirely agnostic to the application sitting on top of the IoTivity stack. The logs should tell us more about what specifically is failing. Thanks, Nathan From: Heldt-Sheller, Nathan Sent: Friday, July 14, 2017 2:13 PM To: 'Alex Kelley' <ale...@microsoft.com<mailto:ale...@microsoft.com>>; Mats Wichmann <m...@wichmann.us<mailto:m...@wichmann.us>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: RE: [dev] many IoTivity samples broken with security Okay thanks for the additional context Alex. Regarding 2428, you are right that without a .dat file at all, the stack *should* generate a default configuration that can be onboarded using RandomPIN. If this is failing, can you please provide the two .log files on the JIRA ticket and re-assign to Randeep? And, I have no idea what the "best" samples to recommend are so you may be right... I'll defer to someone working higher in the stack to say. If these are indeed our two main samples then please change the issue from P3 to P2 (P1 "security" bugs are reserved for Certification blockers that would prohibit us from passing IPR with a working reference implementation). Thanks, Nathan From: Alex Kelley [mailto:ale...@microsoft.com] Sent: Friday, July 14, 2017 2:07 PM To: Heldt-Sheller, Nathan <nathan.heldt-shel...@intel.com<mailto:nathan.heldt-shel...@intel.com>>; Mats Wichmann <m...@wichmann.us<mailto:m...@wichmann.us>>; iotivity-dev@lists.iotivity.org<mailto:iotivity-dev@lists.iotivity.org> Subject: RE: [dev] many IoTivity samples broken with security 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> [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<mailto:m...@wichmann.us>>; iotivity-dev@lists.iotivity.org<mailto: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
