Hi Maxi, IOT-1505 is not about Cloud ACL functionality, it is about mapping CRUDN bits to REST operations and the disambiguation of ?C? bit, etc. I?m not at all familiar with Cloud ACL and related code base but perhaps you should file a JIRA issue on the behavior you describe.
Thanks, Nathan From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of maxi wu Sent: Tuesday, May 23, 2017 3:10 AM To: jihyeok13.kim at samsung.com Cc: iotivity-dev at lists.iotivity.org Subject: Re: [dev] Security in IoTivity JK, there is an issue related to ACL. https://jira.iotivity.org/browse/IOT-1505?jql=project%20%3D%20IOT%20AND%20resolution%20%3D%20Unresolved%20AND%20text%20~%20%22PUT%22%20ORDER%20BY%20priority%20DESC%2C%20updated%20DESC Is this affect only C/C++ stack? or does this also apply to cloud ACL? the ACL of cloud server from 1.2.0 does not check permission of PUT request. Is that intended? if so, why do we want PUT command bypass ACL/ACE checking? AclVerifyResource.checkPermission(), if the rm is PUT, it will pass the verification no matter what permission value is. From: ??? [mailto:[email protected]] Sent: Monday, January 16, 2017 12:34 PM To: maxi wu Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: RE: Re: [dev] Security in IoTivity Hi Maxi, We are working on improving document for ACL. Current implementation is, user can set ACL to each device for different users. Permission 31(CRUDN) in group info means, default ACL policy, set by administrator ( in this case, code configuration). So shared devices are configured using that default permission when they initially shared to group. Device owner can update that device's permission inside of the group. Best Regards JK --------- Original Message --------- Sender : maxi wu <maxi.wu at u-media.com.tw<mailto:maxi.wu at u-media.com.tw>> Date : 2017-01-12 20:16 (GMT+9) Title : Re: [dev] Security in IoTivity While you are discussing SSL and related security features, I want to discuss what ACL does. I am testing the group_invite_sample, I could create/join/add device. I think other members could discover devices which have joined the group. But I also notice there is a permission 31 in group info, what does that mean? Does Iotivity ACL means we could have different permission for each user to a specify device? Or just restriction on device discovery? I couldn?t find any document on ACL. Does OCF spec cover anything on ACL? From: iotivity-dev-bounces at lists.iotivity.org<mailto:iotivity-dev-bounces at lists.iotivity.org> [mailto:[email protected]] On Behalf Of Gregg Reynolds Sent: Tuesday, December 27, 2016 10:12 PM To: Prakash Karthikeyan Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> Subject: Re: [dev] Security in IoTivity On Sun, Dec 25, 2016 at 11:59 PM, Prakash Karthikeyan <prakash.karthikeyan at smartron.com<mailto:prakash.karthikeyan at smartron.com>> wrote: Thanks, Karthikeyan Prakash. On Mon, Dec 26, 2016 at 10:59 AM, Gregg Reynolds <dev at mobileink.com<mailto:dev at mobileink.com>> wrote: On Fri, Dec 23, 2016 at 6:58 PM, Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> wrote: I think this question was already answered by Prakash on Tuesday 12/20, I'm not entirely sure, because the Spec is not exactly a paragon of clarity, but my view is that Prakash's answer was incorrect. Or at least unclear. He said: "IoTivity Secured Servers can be discovered by any Secured Clients. There is nothing like authorization to check whether it is authenticated device." To be honest, I am not at all sure what that means, but I'm pretty sure it's wrong. To me, "secured" means exactly that encryption, authentication, and authorization are enabled. (But "secured" is used very loosely in Iotivity, so who knows?) "Secured Servers" and "Secured Clients" is pretty close to meaningless, since the obvious next question is "Secured how, and for what?". A credentialed client that is not granted permission to read/discover resource "foo" by the server's ACL is still a "Secured Client". This process as I mentioned is only on the initial setup of the Client and Server Communication. In IoTivity it is mentioned as the Ownership Transfer which happens after the discovery part. Initially the Client discovers all the servers which holds Owned=False credential and it can be discovered by any of the clients. After the server is done with OT the ACL comes into picture. Once the OT is done, the server hold the credential about the client which are granted permission to discover. My reply was intended to the particular question and not generalised. One more tidbit: my understanding is that dynamic on-boarding is not a requirement. Device ownership and provisioning can be done statically, at compile time, so to speak. If there are no unowned devices on the network, then discovery will be subject to the usual security constraints, specifically authentication and authorization checks. But even if dynamic on-boarding is supported, I don't see anything in the Spec requiring that all unowned devices must respond favorably to all requests for discovering unowned devices. I don't see why that would be a requirement - a vendor should be able to make its devices discoverable only by certain OnBoarding Tools, for example, and return an error or ignore all other discovery requests. Ownership status is a property of /oic/sec/doxm, which is just a resource, access to which is subject to the usual authentication and authorization constraints. I don't see any special provisions in the Spec making it different from any other resource. Also "clients" are not required to support ownership transfer. Only OnBoarding Tools need to have that capability, as far as I can see; and an OBT need not be an ordinary CRUDN client, it could have OBT functionality and nothing more. FWIW in my test setup I use static security configuration, using PSKs. No runtime ownership transfer, etc. I just ran a test, by setting up my ACL to restrict discovery, and as expected got an OC_STACK_UNAUTHORIZED_REQ when I tried device discovery using a bad subject id for the client. However, I did get a response, my request was not silently ignored. So I guess the real answer to the OP's question is that you can find out all the devices on the network by multicasting just about any request; devices might deny access, but their responses will at least tell you which devices are running the Iotivity stack. You can then unicast GETs on /oic/p, /oic/d, etc. with the correct subject id to get the desired discovery data. HTH, Gregg The The Security spec v. 1.1.1 says, on page 26: "To achieve extensibility and scalability, this specification does not provide a mandate on discoverability of each individual resource. Instead, the OIC server, holding the resource will rely on ACLs for each resource to determine if the requester (the client) is authorized to see/ handle any of the resources." The problem (IMO) is that the specs are rather poorly written. Or maybe "very poorly written" would be more honest. grrrr. The critical point is that "discovery" is not an OCF operation. It's something you do with GET and multicasting, and creds, and ACLs, just like any other resource action. See p. 100 of the security spec, which includes "discover" in the "R" access policy - to allow discovery, your ACL must include that, AFAIK. There is not, to my knowledge, anything in the Spec that addresses discovery as distinct from GET etc. So the discoverability of resources is subject to the same security constraints as any others, which means in particular - to address the OP's question - that it is not the case that "any client capable of discovering whatever device running the stack". Since a "device" is just a resource, like any other. HTH gregg _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev _______________________________________________ iotivity-dev mailing list iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org> https://lists.iotivity.org/mailman/listinfo/iotivity-dev | Jee Hyeok, Kim | IoT Solution Lab, SW Center | Mobile) +82-10-9168-3641 | [cid:image001.gif at 01D2D39D.419CB180] [http://ext.samsung.net/mail/ext/v1/external/status/update?userid=jihyeok13.kim&do=bWFpbElEPTIwMTcwMTE2MDQzNDIxZXBjbXMxcDM4NDE5NjZhYjQ4ZWEyMzU1Y2Q3NzcyNmE4NTM2NjczZCZyZWNpcGllbnRBZGRyZXNzPW1heGkud3VAdS1tZWRpYS5jb20udHc_] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170523/3d6922a9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 13402 bytes Desc: image001.gif URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20170523/3d6922a9/attachment.gif>
