George it is great help.
1) SECURE=0 build 2) SECURE=1 build, Create Resource with non-secure flag. OCCreateResource(?. uint8_t 0) 3) SECURE=1 build, Create Resource with secure flag. OCCreateResource(?. uint8_t OC_SECURE) In 2) case, what is the security mechanism and is it aligned to OCF security? > Encryption is not used but ACLs is used? This is not the option in AllJoyn. >From my IoTivity experience, we don?t need much Wireshark debugging during >IoTivity Application development. Just I felt it is very intriguing action for some additional setting or handling for ACL even though non-secure resource. BR, Uze Choi From: Nash, George [mailto:george.n...@intel.com] Sent: Friday, September 23, 2016 5:08 AM To: uzchoi at samsung.com; Heldt-Sheller, Nathan; 'Gregg Reynolds'; 'Dave Thaler' Cc: iotivity-dev at lists.iotivity.org Subject: RE: [dev] SECURE build flag setting as default configuration AllJoyn decides to use security when the BusObject (AllJoyn?s equivalent to IoTivity?s resource) is registered with the BusAttachment BusAttachment.RegisterBusObject(myObj, securityFlag) If the security flag is false no authentication is needed to access the object. No ACLs are needed for the BusObject. The developer does not need to know anything about security or ACLs to use the BusOject they just need to understand AllJoyns RPC framework. There is no expectation of privacy. With something like Wireshark you could figure out everything about the messages passed between peers. When AllJoyn is using security there are two ways it can be used. 1. Encryption is used but ACLs are not used. If peers can negotiate a secure connection they can talk with each other. This is a result that when AllJoyn security was first created ACLs were not yet done. The security is full end to end security not just the physical connection. 2. Encryption and ACLs are used. If any peer in the uses an ACL then all peers must use ACLs. There are some helper functions to get permissive ACLs that makes the BusObject give full access to the BusObject as long as a secure connection can be negotiated. When security is enabled an application like Wireshark might be able to find out information like who the sender and recipient of a message are but the could not read the content of the message. Last time I looked there was some work being done to prevent an outside program like Wireshark from even being able to read to/from header information but I don?t know what the result of that work was. The level of difficulty for developers learning each gets harder the more you enable: - Using no security easy - Using encryption without ACLs hard but someone that already understands basic security should not find it hard. - Using encryption with ACLs really hard must understand basic security and how to setup and use ACLs. Hope this helps George From: iotivity-dev-bounces at lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of ???(Uze Choi) Sent: Wednesday, September 21, 2016 7:04 PM To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; 'Gregg Reynolds' <dev at mobileink.com>; 'Dave Thaler' <dthaler at microsoft.com> Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] SECURE build flag setting as default configuration Hi, Nathan, >From the product release perspective, you may right. However, from the product development cycle view, something stange. Let?s think about that developer uses the Windows or Tizen which has the library in OS. Initially, as a study, people run the sample application. Second, make the initial product code without secure disable. Finally, developer enable the security into the resource and test. With SECURED=1 build, we only have the option to make the secure resource or non-secure resource, by value setting as like OCCreateResource(?. uint8_t OC_SECURE or 0). In case of non-secure resource setting, it will be very cumbersome that user should do a certain action such as placing the ACL related configuration file or so. Do the Alljoyn also require that step? What about the http browsing? I?m not sure that security WG guides the operation of non-secure resource also? If so, they needs to consider the development cycle also. BR, Uze Choi From: <mailto:iotivity-dev-bounces at lists.iotivity.org> iotivity-dev-bounces at lists.iotivity.org [ <mailto:iotivity-dev-bounces at lists.iotivity.org> mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Heldt-Sheller, Nathan Sent: Thursday, September 22, 2016 9:29 AM To: Gregg Reynolds; Dave Thaler Cc: <mailto:iotivity-dev at lists.iotivity.org> iotivity-dev at lists.iotivity.org Subject: Re: [dev] SECURE build flag setting as default configuration Hi folks, To clarify, the ?runtime option? (#2 and #3) is not equivalent to the compile switch Greg was describing. The runtime option simply allows for ?unsecure? vertical resources (aka application resources) to be created in such a way that they can be accessed anonymously (e.g. via CoAP). This is as opposed to requiring authenticated access (e.g. via CoAPS) for ?secure? vertical resources. In contrast, the SECURED=0 build flag removes portions of the security functionality from the stack, in an attempt to make legacy applications and unit tests (those written before the security layer was added) function without having to adapt to the security model. Whether or not such a build is still required, I do not know, but I think that at the very least the SECURED=1 mode should be the default ? and the only certifiable ? build option. And if I had to throw my two cents in, I?d also vote for removing the SECURED=0 build option entirely, unless we have a clear requirement to keep it, as it has been (and continues to be) a source of confusion and complexity. All the apps and units tests that have not yet been adapted to the security model will have to be updated (e.g. ACL entries added for vertical resources, etc.) but this seems like a better option than perpetuating a confusing and superfluous build flag. Thanks, Nathan From: <mailto:iotivity-dev-bounces at lists.iotivity.org> iotivity-dev-bounces at lists.iotivity.org [ <mailto:iotivity-dev-bounces at lists.iotivity.org> mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Wednesday, September 21, 2016 4:46 PM To: Dave Thaler < <mailto:dthaler at microsoft.com> dthaler at microsoft.com> Cc: <mailto:iotivity-dev at lists.iotivity.org> iotivity-dev at lists.iotivity.org Subject: Re: [dev] SECURE build flag setting as default configuration On Sep 21, 2016 6:34 PM, "Dave Thaler" <dthaler at microsoft.com> wrote: > > Two responses? > > > > Gregg wrote: > > ? fwiw imho SECURED should be removed from the build system altogether. > Non-encryption security features should just always be enabled. > > > > Agree. > > > > ? But for debugging, something like --DISABLE_DTLS should be supported by > the build logic > > > Disagree. Debugging does not require a build-time option, just a run-time > option as Uze and I mentioned. > ok, but what kind of debugging? if you need to debug packets over the wire you need to disable dtls. But if you need to debug ACLs etc. maybe not? by "runtime option" do you refer to setting security for resources? it seems to me that a runtime option to turn off dtls is problematic. it would introduce a whole 'nother security issue to guard this, which AFAIK is not adressed by the OIC protocol dpec. (Bear with me, I'm still learning this stuff). gregg > Uze subsequently wrote: > > > By investigating several option for secure resource setting by real > > execution, I can list up the three possible ways. > > 1) SECURE=0 build > > 2) SECURE=1 build, Create Resource with non-secure flag. > OCCreateResource(?. uint8_t 0) > > 3) SECURE=1 build, Create Resource with secure flag. OCCreateResource(?. > uint8_t OC_SECURE) > > > > We should delete way #1 and leave ways 2 and 3. The ?SECURED? flag can then > be deleted since it?s always 1. > > > > Dave > > > > From: Gregg Reynolds [mailto:dev at mobileink.com] > Sent: Wednesday, September 21, 2016 7:05 AM > To: Dave Thaler <dthaler at microsoft.com> > Cc: iotivity-dev at lists.iotivity.org; Thiago Macieira <thiago.macieira at > intel.com> > Subject: RE: [dev] SECURE build flag setting as default configuration > > > > On Sep 20, 2016 4:27 PM, "Dave Thaler" <dthaler at microsoft.com> wrote: > > > > I've now thought about this some more and I am now convinced that we should > > remove > > support for SECURE=0 builds (in master). > > > > As Uze mentioned, the choice to disable security should be a > > config/run-time decision, not > > a compile-time decision. There is no reason to consume build resources to > > build a version > > that cannot even be configured to enable security. > > > agreed in general but I think there is still a "problem", namely that > "security" conflates multiple distinct functionalities. encryption is one > thing; creds are another, and ACLs yet another. > > fwiw imho SECURED should be removed from the build system altogether. > Non-encryption security features should just always be enabled. But for > debugging, something like --DISABLE_DTLS should be supported by the build > logic. > > this suggests also that that API should be changed. OCInit should be > parameterized by persistent storage, and client code should not have to > separately call an init function for persistent storage. in other words > there should not be two ways to get going, one for SECURED=0 and one for > SECURED=1. client app code should never need to make a secured/unsecured > distinction. of course apps can still designate resources as secure or not > but that is a completely separate topic. > > my 2 cents. > > gregg -------------- next part -------------- HTML ?????? ??????????????... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160923/638f3c1d/attachment.html>
