Very interesting discussion. Thank you all for the contributions and feedback.
BR, Khaled On Mon, Dec 26, 2016 at 9:32 PM, Heldt-Sheller, Nathan < nathan.heldt-sheller at intel.com> wrote: > 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:dev at mobileink.com] > *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> 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/20161227/196db5b0/attachment.html>
