Hi Nathan
Just wanted to confirm that json2cbor from iotivity-2.0.0 and latest master
both fail when an ACE contains a roletype entry.
For the provisioning client example, is there anyway to inspect the .dat
files that are modified after the provisioning is performed? Something like
a cbor2json if there is such a tool.
Thanks
Khaled
On Wed, Nov 21, 2018 at 9:56 AM Khaled Elsayed <khaledi...@gmail.com> wrote:
> 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 (#10024):
https://lists.iotivity.org/g/iotivity-dev/message/10024
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]
-=-=-=-=-=-=-=-=-=-=-=-
