Thanks Nathan so much for the detailed responses. I was using the master
branch which I believe is based on 1.4. I just downloaded 2.0.0 and will
use it for the experimentation.
My replies below inline.
On Tue, Nov 20, 2018 at 8:40 PM Heldt-Sheller, Nathan <
nathan.heldt-shel...@intel.com> wrote:
> 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
>
>
>
>
>
> 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)…
>
[KE] OK, I agree.
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.
>
[KE] OK, I will try that and get it to work first. Thanks for confirming I
am going in the right direction.
>
>
> 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.
>
[KE] Yes, I am using the master I got sometime in October. I will re-test
using 2.0.0 release and let you know how it goes.
> 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.
>
[KE] Yes, I started playing with the sampleserver_mfg application along
with the provisioning tool and it works nicely. I will start digging into
the code to understand how the certificate business is handled.
Could you also share some example on Cred entries using symmetric
authentication listing the Role(s) of the client.
Thanks again and best regards,
Khaled
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#10020):
https://lists.iotivity.org/g/iotivity-dev/message/10020
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]
-=-=-=-=-=-=-=-=-=-=-=-
