Great questions Khaled and I’m quite impressed with how far you have gotten on your own! Well done.
Responses inline [NHS]. One question for you: I hope you are using the latest IoTivity code base (the 2.0.0 release, tagged “2.0.0” in IoTivity, is a good starting point). Can you clarify which version you’re working with? Thanks, Nathan From: iotivity-dev@lists.iotivity.org [mailto:iotivity-dev@lists.iotivity.org] On Behalf Of Khaled Elsayed Sent: Tuesday, November 20, 2018 5:06 AM To: iotivity-dev <iotivity-dev@lists.iotivity.org> Subject: [dev] Some security question As I posted earlier, I am working on a mqtt-ocf gateway. As a start, I am trying to deploy security on the OCF side. The proxy creates resources corresponding to the MQTT topics on the fly for both subscribe and publish request if the topic is new. This works perfectly and I tested that OCF clients can discover and access the created resources and when an MQTT publisher publishes a new value for the topic, it is pushed via notification to the OCF client or the OCF can perform GET/PUT at its pace. This works perfectly as long as security is not involved. Now, if I want to the MQTT proxy to serve only authorized clients, I have a puzzle. The proxy does not know the resources in advance. They are created on the fly. So, I have two problems here: [NHS] this is going to be difficult to begin with, as /acl2 management is done by the Access Mgmt Svc (AMS), part of the Onboarding Tool (OBT). The application layer is not intended to manage access control policy on a Device. So you’ll need to use wildcards. As you surmised, this is best done via “Roles” (security Device groups)… 1. ACL: I would like to create a new ACE for the created resource with something like: { "aceid": n, // n is the number of resource created "subject": {"conntype": "auth-crypt"}, "resources":[ { "href":"</a/mqtt/mqtt_topic>", // the resource created for the mqtt "rt" : ["oic.r.mqtt"], "if" : ["oic.if.baseline", "oic.if.a"]} ], "permission": 22 } Which API should I call to add this new ACL? What is the format used to represent the ACL? [NHS] As mentioned above, this would need to be added by the AMS/OBT, not the Device itself. There should not be an API to do this, as it would create a security vulnerability if application layer code could modify the /acl2 Resource directly. I am trying to avoid using wildcard, it is possible to have an ACL like the following from the beginning and it should work (as far as I know) { "aceid": n, // n is the number of resource created "subject": {"conntype": "auth-crypt"}, "resources":[ { "wc": "+" // all secured resources created } ], "permission": 22 } [NHS] Yes this is what I would test to begin with and make sure everything works using a wildcard Access Control Entry (ACE) before proceeding to attempt to make Roles work. 2. I asked before in the list about group symmetric keys and did not get answers. So, I checked the source code, and currently it is not supported. So, I found the following in "OCF Security Primer for Device Vendors" [NHS] I’m sorry I missed your earlier question. You are correct again: while we do have allowed cipher suites in the Security Specification that theoretically support GSK but they are not specified, or supported in IoTivity. Vendor-defined groups, via “roletype” Parameter of the ACE2 “subject” property: { "aceid": 1, "subject": { "roletype": “<made_up_string_that_matches_string_in_cred>” }, ... } So, I tried to modify the SVR json file according to the above template, and added a cred record with matching string. When I run json2cbor, it fails. If I change the roletype to uuid, it works, so there is no syntax error in the json file. [NHS] Per above question, what version of IoTivity are you using? I have not tested Roles behavior myself, but I know the Roles tests in the Certification Test Tool (CTT) pass, so I believe the functionality is correct. If you are using the latest “master”, or even the “2.0.0” release, then I suspect we just need to figure out what is going on with the json2cbor tool. Anyway, here is my question: I would like to define a security group any member of which can access the created resource. I don't want to populate the proxy cred list with a separate entry for each new client. Can I use certificates for this? Is there an example of using certificates to allow clients with proper credentials to authenticate with an OCF server? [NHS] Security Groups (“Roles” in OCF) do not *require* asymmetric crypto-based authentication, but it certainly works more smoothly that way. The symmetric approach requires that each /cred entry (yes, one /cred entry per Client Device) must list the Role(s) that the Client corresponding to that entry belongs to. On the other hand, as you’ve surmised, Certificate-based authentication is indeed one way to avoid creating /cred entries for each Subject (Client Device). There is indeed an example of Certificate-based Client/Server authentication in the IoTivity example “sampleserver_mfg”, which is in the resource/csdk/securitiy/provisioning/sample folder. We’re working on documentation improvement on the wiki to point out critical examples like this one. Give it a try (start the sampleserver_mfg, then onboard it with the sample provisioningclient app in the same output directory). Let me know if you have any issues. Thanks for any pointers :) BR, Khaled -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#10019): https://lists.iotivity.org/g/iotivity-dev/message/10019 Mute This Topic: https://lists.iotivity.org/mt/28267159/21656 Group Owner: iotivity-dev+ow...@lists.iotivity.org Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
