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@...<mailto:iotivity-dev@...>> on behalf of
"teo@...<mailto:teo@...>" <teo@...<mailto:teo@...>>
Date: Monday, October 29, 2018 at 2:25 AM
To: "iotivity-dev@...<mailto:iotivity-dev@...>"
<iotivity-dev@...<mailto: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 (#9997):
https://lists.iotivity.org/g/iotivity-dev/message/9997
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]
-=-=-=-=-=-=-=-=-=-=-=-
