Thanks for reviewing my CTT results,
I've checked commenting out calls to oc_resource_make_public() in oc_acl.c
doesn't break any other tests.
Thanks,
Taehwa
On Mon, Nov 5, 2018 at 05:47 PM, Kishen Maloor wrote:
>
>
>
> Hello,
>
>
>
>
>
>
>
> Thanks. I spent time reviewing your CTT results and investigating the
> issues. Here are my findings:
>
>
>
>
>
>
>
> 1) Through offline discussions with Mitch Kettrick, I've learnt that
> currently the Smart Home spec absolutely requires
>
>
>
> all vertical resources to not expose a "coap" endpoint. The CTT has a test
> case just to verify this, and hence returns that failure.
>
>
>
>
>
>
>
> 2) The acl2 implementation in IoTivity-Lite intended to be smart, and
> dynamically (at runtime) attaches "coap" endpoints to all resources
>
>
>
> referred to by an anon-clear ACE. When an anon-clear ACE is removed, it
> automatically detaches "coap" endpoints from those resources.
>
>
>
>
>
>
>
> This was done so the ACL configuration would authoritatively dictate if a
> Server's resource could be accessed via an unencrypted connection
>
>
>
> without having to potentially recompile an application to expose "coap"
> endpoints.
>
>
>
> Furthermore, the dynamic nature of including/excluding endpoints would
> keep payload sizes lower by excluding "coap" endpoints when
>
>
>
> there isn't an ACE granting anon-clear access.
>
>
>
>
>
>
>
> However, that requirement of the SH spec contradicts this feature, and as
> such the "solution" for now may at a minimum be largely what
>
>
>
> you've already tried, i.e. to not call oc_resource_make_public() on
> application resources from acl2 while processing an anon-clear
>
>
>
> ACE. (By the way, kudos to you for figuring that out on your own; I
> appreciate your due diligence :-)).
>
>
>
>
>
>
>
> > I wonder we have to add unsecure(e.g. coap://) endpoints to resources
> for the anon-clear ACE which has "wc" : "*".
>
>
>
>
>
>
>
> Well, that is at the crux of this discussion, which ties into the
> applicability of an anon-clear ACE in the absence of a "coap" endpoint.
> Lite's
>
>
>
> acl2 implementation intended to guarantee that if you had an anon-clear
> ACE, you could at a minimum access a resource via the "coap"
>
>
>
> endpoint. You could also access it via the "coaps" endpoint of course, if
> you had credentials provisioned, but that couldn't be
>
>
>
> guaranteed. Hence...
>
>
>
>
>
>
>
> 3) On reviewing another failure in your results, I was able to spot a
> separate bug in the acl2 implementation and have prepared a
>
>
>
> patch for it.
>
>
>
>
>
>
>
> I will try to post the fixes for 1) and 3) this week.
>
>
>
>
>
>
>
> In the meanwhile, if you could confirm that commenting out calls to
> oc_resource_make_public() in oc_acl.c does not break any other TCs,
>
>
>
> that would be good information for us to have.
>
>
>
>
>
>
>
> If there are any other failures, please send over your CTT results to
> Mitch Kettrick and myself and we'll help you get them sorted out.
>
>
>
>
>
>
>
> Thanks,
>
>
>
> -Kishen.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
> Kishen Maloor
>
>
>
>
> Intel Open Source Technology Center
>
>
>
>
>
>
>
> *From:* <iotivity-dev@lists.iotivity.org> on behalf of "t...@vinetech.co.kr"
> <t...@vinetech.co.kr>
> *Date:* Monday, November 5, 2018 at 4:55 PM
> *To:* "iotivity-dev@lists.iotivity.org" <iotivity-dev@lists.iotivity.org>
> *Subject:* [dev] [IoTivity-Lite] Question about oc_sec_decode_acl
> function's behavior calling oc_resource_make_public
>
>
>
>
>
>
>
>
>
> Hello! Thanks for replying.
>
> I am not sure whether it is a bug of CTT.
> Yes, I am testing in OCF 1.3 and icv version declared in PICS file is "ocf
> 1.3.0" and I am working on the latest code in the
> iotvity/iotvity-constrained repo.
> I understand that oc_resource_make_public(r) make the resources available
> through an unsecure connection for the anon-clear ACE.
> I wonder we have to add unsecure(e.g. coap://) endpoints to resources for
> the anon-clear ACE which has "wc" : "*".
>
> Though Mr Kettrick said the below(1) is not related to the ACE, but I've
> checked that the resources which doesn't have any unsecure enpoints do
> have
> unsecure endpoints after the below(2) ACE is added to the ACL2 by the
> oc_resource_make_public function in the oc_sec_decode_acl function.
>
> (1) - (For Smart Home Devices, Vertical Resources with OCF-defined "rt"
> values shall
> not expose any unsecured Endpoints (e.g. CoAPs)(10.2.4 Endpoint
> information in
> "eps" Parameter [CORE], 8 Security [DEV]).)
>
> (2) - ({"subject" : {"conntype": "anon-clear"},
> "resources": [
> wc: "*"
> ],
> "permission":2
> })
>
> I attached my octt file and PICS file for the test.
>
> Thanks
> -Taehwa
>
> --
>
> Mitch Kettrick <cpm@...>
>
>
>
>
> Oct 29 #9966 ( https://lists.iotivity.org/g/iotivity-dev/message/9966 )
>
>
>
>
>
>
>
>
>
> Hi,
>
>
>
>
>
>
>
> Having the .octt file will help but the issue you're reporting:
>
>
>
>
>
>
>
> For Smart Home Devices, Vertical Resources with OCF-defined "rt" values
> shall
> not expose any unsecured Endpoints (e.g. CoAPs)(10.2.4 Endpoint
> information in
> "eps" Parameter [CORE], 8 Security [DEV]).
>
>
>
>
>
>
>
> This has nothing to do with ACEs. It appears that there is a Vertical
> Resource that is exposing a "coap" Endpoint when they should all be
> "coaps". Seeing the actual log file will help debug this issue.
>
>
>
>
>
>
>
> In addition, as Kishen mentioned, it's also important to know which
> version of the spec you're testing against (i.e. "icv" version declared in
> the PICS and exposed by the IUT) because the definition of "*" changed
> between OCF 1.3 and OCF 2.0. This should have nothing to do with the
> failure you noted but it's more of a reminder that "*" means different
> things in different versions of the security spec.
>
>
>
>
>
>
>
> Mitch
>
>
>
>
>
>
>
> *From:* Maloor, Kishen [mailto:kishen.maloor@...]
> *Sent:* Monday, October 29, 2018 10:55 AM
> *To:* teo@...; iotivity-dev@...
> *Cc:* Mitch Kettrick
> *Subject:* Re: [dev] [IoTivity-Lite] Question about oc_sec_decode_acl
> function's behavior calling oc_resource_make_public
>
>
>
>
>
>
>
>
> Hello,
>
>
>
>
>
>
>
> Thanks. Are we sure this isn't a bug in the CTT? I ask because the CTT
> provisions ACEs, and if thats the ACE
>
>
>
> it provisioned during the test case, at least on the surface it appears
> that the code is doing the right thing.
>
>
>
>
>
>
>
> At a minimum, it might help to look at your test results as recorded by
> the CTT. That will help people identify the issue
>
>
>
> in the code and/or the CTT.
>
>
>
>
>
>
>
> Regarding the code block you highlighted, oc_resource_make_public(r) just
> instructs the upper layer to (additionally) include the
>
>
>
> coap:// (unsecure) endpoint in any future discovery responses. An
> anon-clear ACE enables you to access resources through an unsecure
> connection.
>
>
>
> So, calling this API ensures consistency between the ACE and the resource
> object on the application layer irrespective of how the application
>
>
>
> initialized that resource object. The default behavior is to expose only
> secure endpoints.
>
>
>
> By commenting out that line, you're having it go against what the ACE
> allows you to do.
>
>
>
>
>
>
>
> I assume you're testing for OCF 1.3 and with code from the master branch.
>
>
>
>
>
>
>
> Thanks,
>
>
>
> -Kishen.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
> Kishen Maloor
>
>
>
>
> Intel Open Source Technology Center
>
>
>
>
>
>
>
> *From: * < iotivity-dev@... > on behalf of " teo@... " < teo@... >
> *Date: * Monday, October 29, 2018 at 2:25 AM
> *To: * " iotivity-dev@... " < iotivity-dev@... >
> *Subject: * [dev] [IoTivity-Lite] Question about oc_sec_decode_acl
> function's behavior calling oc_resource_make_public
>
>
>
>
>
>
>
>
>
> Hello, iotivity-dev!
>
> I'm preparing OCF Certification and I'm doing it using IoTivity-Lite.
> When I'm testing CT1.1.6 OCF Endpoint the problem occurs.
>
> In CT1.1.6, before starting the test, an ACE which grants "anon-clear"
> access to
> any Resource that has a CoAP Endpoint is added.
> (It looks like following.
> {"subject" : {"conntype": "anon-clear"},
> "resources": [
> wc: "*"
> ],
> "permission":2
> })
>
> When this request is posted, post_acl function is called and post_acl
> function calls
> oc_sec_decode_acl function.
> And inside of this function,
> Following part changes all the app resource to be public(unsecure).
> And this makes the test fail by following reason.
> (For Smart Home Devices, Vertical Resources with OCF-defined "rt" values
> shall
> not expose any unsecured Endpoints (e.g. CoAPs)(10.2.4 Endpoint
> information in
> "eps" Parameter [CORE], 8 Security [DEV]).)
>
>
>
> #ifdef OC_SERVER
>
>
>
> if (subject_type == OC_SUBJECT_CONN &&
>
>
>
> subject.conn == OC_CONN_ANON_CLEAR) {
>
>
>
> if (href) {
>
>
>
> oc_resource_t *r =
>
>
>
> oc_ri_get_app_resource_by_uri(href, strlen(href), device);
>
>
>
>
> if (r) {
>
>
>
> oc_resource_make_public(r);
>
>
>
> }
>
>
>
> } else {
>
>
>
> oc_resource_t *r = oc_ri_get_app_resources();
>
>
>
> while (r != NULL) {
>
>
>
> if ((r->properties & wc_r) == r->properties) {
>
>
>
> oc_resource_make_public(r);
>
>
>
> }
>
>
>
> r = r->next;
>
>
>
> }
>
>
>
> }
>
>
>
> }
>
>
>
>
>
>
>
> #endif /* OC_SERVER */
>
>
>
>
> So, making the test pass, I commented out the line
> 'oc_resource_make_public(r);'
> and I could pass the test. But I wonder I did right thing to modify the
> api in person.
>
> Please check out this and let me know the right way me to pass the
> CT1.1.6.
>
> Thanks in advance.
>
>
>
>
>
>
>
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#9998):
https://lists.iotivity.org/g/iotivity-dev/message/9998
Mute This Topic: https://lists.iotivity.org/mt/27865370/21656
Group Owner: iotivity-dev+ow...@lists.iotivity.org
Unsubscribe: https://lists.iotivity.org/g/iotivity-dev/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
