Hi Gregg, Sorry, I was referring to Prakash?s prior answer where he pointed to documentation, not the answer regarding authentication. My mistake for not being specific!
Yes, the other discussion about authentication was not clear to me, either. To give a brief summary: the authentication requirement is determined by the type of credential used, and by the onboarding technique (the ?Owner Transfer Method? or OTM) which was used to ?onboard? the device (that is, to ?pair? the device, or ?join? it to the network). If the credential being used is a symmetric PSK (pre-shared key) then the authentication is as good as the key-provisioning mechanism (another way of saying: if we rely on both of us having the same key, then the authentication is only as good as the authentication needed to get that key in the first place). For OIC?s ?Just Works? OTM, the authentication is based on a first-come-first-served model: the first Client to arrive to a new ?unpaired? or ?unowned? Server device can take ownership and establish the PSK, and thereafter is able to authenticate as the device owner. If the ?Manufacturer Certificate Based? OTM is used instead, then the credential being used is a manufacturer certificate, and the authentication is traced back to a root of trust, e.g. a certificate authority (CA). This is a stronger OTM in that a CA can verify the authenticity of the cert used to connect and therefore it?s not a first-come-first-served model, but a controlled certificate provisioning model? the manufacturer controls who gets a certificate, and a Server device knows that not just any old Client will be able to take ownership of it. However, all of this info (other than the term ?OTM?) is just general security stuff? not specific to IoTivity. So I?m not sure that it really belongs in the OIC/OCF Specifications, per-se. There was an attempt to provide some informative/editorial information but I think it largely created more confusion than it was worth. The really important part of the OIC spec for IoTivity developers is the Security Virtual Resource (SVR) normative text, which describes the Resources which define the Security Configuration of the device. I?d suggest anyone who wants to work directly in the IoTivity Security Code must understand those SVRs thoroughly. Thanks, Nathan From: Gregg Reynolds [mailto:[email protected]] Sent: Sunday, December 25, 2016 9:30 PM To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com> Cc: Khaled Elsayed <khaledieee at gmail.com>; iotivity-dev at lists.iotivity.org Subject: Re: [dev] Security in IoTivity On Fri, Dec 23, 2016 at 6:58 PM, Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>> wrote: I think this question was already answered by Prakash on Tuesday 12/20, I'm not entirely sure, because the Spec is not exactly a paragon of clarity, but my view is that Prakash's answer was incorrect. Or at least unclear. He said: "IoTivity Secured Servers can be discovered by any Secured Clients. There is nothing like authorization to check whether it is authenticated device." To be honest, I am not at all sure what that means, but I'm pretty sure it's wrong. To me, "secured" means exactly that encryption, authentication, and authorization are enabled. (But "secured" is used very loosely in Iotivity, so who knows?) "Secured Servers" and "Secured Clients" is pretty close to meaningless, since the obvious next question is "Secured how, and for what?". A credentialed client that is not granted permission to read/discover resource "foo" by the server's ACL is still a "Secured Client". The Security spec v. 1.1.1 says, on page 26: "To achieve extensibility and scalability, this specification does not provide a mandate on discoverability of each individual resource. Instead, the OIC server, holding the resource will rely on ACLs for each resource to determine if the requester (the client) is authorized to see/ handle any of the resources." The problem (IMO) is that the specs are rather poorly written. Or maybe "very poorly written" would be more honest. grrrr. The critical point is that "discovery" is not an OCF operation. It's something you do with GET and multicasting, and creds, and ACLs, just like any other resource action. See p. 100 of the security spec, which includes "discover" in the "R" access policy - to allow discovery, your ACL must include that, AFAIK. There is not, to my knowledge, anything in the Spec that addresses discovery as distinct from GET etc. So the discoverability of resources is subject to the same security constraints as any others, which means in particular - to address the OP's question - that it is not the case that "any client capable of discovering whatever device running the stack". Since a "device" is just a resource, like any other. HTH gregg -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161226/5348a0a9/attachment.html>
