Hi Gregg, TLS and Access Control are indeed separate things. However, OCF currently uses the DTLS session as a means of authenticating a Client, which is in turn how identity is determined for purposes of Access Control. So in this way TLS authentication and access control are closely tied.
I’d agree with you that the OCF Specifications don’t contain a security primer, that would introduce and distinguish between authentication (which currently takes place via DTLS handshake) and authorization (which is handled by the Access Control mechanism). Another point of agreement is that it is certainly confusing to consider that the Resource creation API “OC_SECURE” flag only creates a “secure” (CoAPS) endpoint for the Resource, but does nothing to modify Access Control policy. In other words, the Resource creation API doesn’t affect the /acl2 Resource. This is correct however, if you consider that the OCF Security Architecture doesn’t allow Applications to modify Device Access Control policy… this is the job of the Access Mgmt Service, and is beyond the privileges of a typical application. Still, the correctness of this from a security standpoint – while important to understand – doesn’t mean it’s not confusing! You’re not the first to point this out, believe me ☺ I’m working on a change for the next OCF Specification (and implementation in IoTivity) that will hopefully improve the intuitive nature of “OC_SECURE” and /acl2 configuration for many Devices, without breaking the security model. I can’t share more than that on the IoTivity reflector at this point but if you’re curious you can join the OCF Security Working Group and take a look at the proposal. Thanks, Nathan From: iotivity-dev-boun...@lists.iotivity.org [mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds Sent: Friday, January 5, 2018 1:31 PM To: iotivity-dev <iotivity-dev@lists.iotivity.org> Subject: [dev] Systematic ambiguity of "secured" Security is a house of many mansions. Data integrity, confidentiality, non-repudiatability, authorization, authentication, etc. The Iotivity docs systematically conflate these attributes, resulting in confusion for devs who are not sec experts. Transport-layer security and access control security are totally orthogonal. The former is about integrity and confidentiality; the latter is about, well, something else. But every bit of Iotivity doc I have seen fails to make that critical distinction. If we want to increase uptake of OCF, this is a problem. For example, it is just wrong to say that OC_SECURE means a resource is secure. It only means that access to the resource must go thru d/tls. That's about the endpoint connection, not the resource. Access control is a completely separate issue afaik. The we have compiling with SECURED or not. Alas, I have not yet come up with better language. But if we want to attract devs we need clearer language. G
_______________________________________________ iotivity-dev mailing list iotivity-dev@lists.iotivity.org https://lists.iotivity.org/mailman/listinfo/iotivity-dev
