[dev] Security in IoTivity

[김지혁]

An HTML attachment was scrubbed...
URL: 

-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 13402 bytes
Desc: not available
URL: 

[dev] Security in IoTivity

[maxi wu]

While you are discussing SSL and related security features, I want to discuss 
what ACL does.

I am testing the group_invite_sample, I could create/join/add device. I think 
other members could discover devices which have joined the group.

But I also notice there is a permission 31 in group info, what does that mean?

Does Iotivity ACL means we could have different permission for each user to a 
specify device? Or just restriction on device discovery?

I couldn?t find any document on ACL. Does OCF spec cover anything on ACL?



From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds
Sent: Tuesday, December 27, 2016 10:12 PM
To: Prakash Karthikeyan
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Security in IoTivity







On Sun, Dec 25, 2016 at 11:59 PM, Prakash Karthikeyan  wrote:






Thanks,

Karthikeyan Prakash.



On Mon, Dec 26, 2016 at 10:59 AM, Gregg Reynolds  wrote:





On Fri, Dec 23, 2016 at 6:58 PM, Heldt-Sheller, Nathan  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".



This process as I mentioned is only on the initial setup of the Client and 
Server Communication. In IoTivity it is mentioned as the Ownership Transfer 
which happens after the discovery part. Initially the Client discovers all the 
servers which holds Owned=False credential and it can be discovered by any of 
the clients. After the server is done with OT the ACL comes into picture. Once 
the OT is done, the server hold the credential about the client which are 
granted permission to discover. My reply was intended to the particular 
question and not generalised. 





One more tidbit: my understanding is that dynamic on-boarding is not a 
requirement. Device ownership and provisioning can be done statically, at 
compile time, so to speak.  If there are no unowned devices on the network, 
then discovery will be subject to the usual security constraints, specifically 
authentication and authorization checks.



But even if dynamic on-boarding is supported, I don't see anything in the Spec 
requiring that all unowned devices must respond favorably to all requests for 
discovering unowned devices.  I don't see why that would be a requirement - a 
vendor should be able to make its devices discoverable only by certain 
OnBoarding Tools, for example, and return an error or ignore all other 
discovery requests.  Ownership status is a property of /oic/sec/doxm, which is 
just a resource, access to which is subject to the usual authentication and 
authorization constraints.  I don't see any special provisions in the Spec 
making it different from any other resource.



Also "clients" are not required to support ownership transfer.  Only OnBoarding 
Tools need to have that capability, as far as I can see; and an OBT need not be 
an ordinary CRUDN client, it could have OBT functionality and nothing more.



FWIW in my test setup I use static security configuration, using PSKs.  No 
runtime ownership transfer, etc.  I just ran a test, by setting up my ACL to 
restrict discovery, and as expected got an OC_STACK_UNAUTHORIZED_REQ when I 
tried device discovery using a bad subject id for the client.



However, I did get a response, my request was not silently ignored.  So I guess 
the real answer to the OP's question is that you can find out all the devices 
on the network by multicasting just about any request; devices might deny 
access, but their responses will at least tell you which devices are running 
the Iotivity stack.  You can then unicast GETs on /oic/p, /oic/d, etc. with the 
correct subject id to get the desired discovery data.



HTH,



Gregg



The  



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 t

[dev] Security in IoTivity

[Gregg Reynolds]

On Jan 5, 2017 11:47 AM, "Thiago Macieira" 
wrote:

Em ter?a-feira, 20 de dezembro de 2016, ?s 13:00:22 PST, Ashwini Sharma
escreveu:
> Hello,
>
> There is no authorization from device on discovery. Any client can
discover
> the devices aroun which are discoverable.

But you can't know what the device is unless you establish a secure (DTLS)
connection to that device and pass authorisation.


to clarify: you mean that you cannot discover the properties of /oic/d
unless you do DTLS?  as opposed to discovering that there is a device
there, at that address, which even a DENIED response will tell you.  I
think. ;)
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Khaled Elsayed]

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 
> *Cc:* Khaled Elsayed ; 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. g.
>
>
>
> The critical point is that "discovery" is  not an OCF o

[dev] Security in IoTivity

[Gregg Reynolds]

On Sun, Dec 25, 2016 at 11:59 PM, Prakash Karthikeyan <
prakash.karthikeyan at smartron.com> wrote:

>
>
> Thanks,
> Karthikeyan Prakash.
>
> On Mon, Dec 26, 2016 at 10:59 AM, Gregg Reynolds 
> wrote:
>
>>
>>
>> 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".
>>
>
> This process as I mentioned is only on the initial setup of the Client and
> Server Communication. In IoTivity it is mentioned as the Ownership Transfer
> which happens after the discovery part. Initially the Client discovers all
> the servers which holds Owned=False credential and it can be discovered by
> any of the clients. After the server is done with OT the ACL comes into
> picture. Once the OT is done, the server hold the credential about the
> client which are granted permission to discover. My reply was intended to
> the particular question and not generalised.
>
>
One more tidbit: my understanding is that dynamic on-boarding is not a
requirement. Device ownership and provisioning can be done statically, at
compile time, so to speak.  If there are no unowned devices on the network,
then discovery will be subject to the usual security constraints,
specifically authentication and authorization checks.

But even if dynamic on-boarding is supported, I don't see anything in the
Spec requiring that all unowned devices must respond favorably to all
requests for discovering unowned devices.  I don't see why that would be a
requirement - a vendor should be able to make its devices discoverable only
by certain OnBoarding Tools, for example, and return an error or ignore all
other discovery requests.  Ownership status is a property of /oic/sec/doxm,
which is just a resource, access to which is subject to the usual
authentication and authorization constraints.  I don't see any special
provisions in the Spec making it different from any other resource.

Also "clients" are not required to support ownership transfer.  Only
OnBoarding Tools need to have that capability, as far as I can see; and an
OBT need not be an ordinary CRUDN client, it could have OBT functionality
and nothing more.

FWIW in my test setup I use static security configuration, using PSKs.  No
runtime ownership transfer, etc.  I just ran a test, by setting up my ACL
to restrict discovery, and as expected got an OC_STACK_UNAUTHORIZED_REQ
when I tried device discovery using a bad subject id for the client.

However, I did get a response, my request was not silently ignored.  So I
guess the real answer to the OP's question is that you can find out all the
devices on the network by multicasting just about any request; devices
might deny access, but their responses will at least tell you which devices
are running the Iotivity stack.  You can then unicast GETs on /oic/p,
/oic/d, etc. with the correct subject id to get the desired discovery data.

HTH,

Gregg


> The
>
>>
>> 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. g.
>>
>> 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 

[dev] Security in IoTivity

[Prakash Karthikeyan]

Thanks,
Karthikeyan Prakash.

On Mon, Dec 26, 2016 at 10:59 AM, Gregg Reynolds  wrote:

>
>
> 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".
>

This process as I mentioned is only on the initial setup of the Client and
Server Communication. In IoTivity it is mentioned as the Ownership Transfer
which happens after the discovery part. Initially the Client discovers all
the servers which holds Owned=False credential and it can be discovered by
any of the clients. After the server is done with OT the ACL comes into
picture. Once the OT is done, the server hold the credential about the
client which are granted permission to discover. My reply was intended to
the particular question and not generalised.

The

>
> 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. g.
>
> 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
>
> ___
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Gregg Reynolds]

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. g.

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: 

[dev] Security in IoTivity

[Heldt-Sheller, Nathan]

I think this question was already answered by Prakash on Tuesday 12/20, but 
there are also additional documents that should be helpful in understanding 
IoTivity security on the wiki:

https://wiki.iotivity.org/iotivity_security

They are not entirely up to date, but still mostly accurate and should give a 
good high-level understanding.

Thanks,
Nathan

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Gregg Reynolds
Sent: Friday, December 23, 2016 4:40 PM
To: Khaled Elsayed 
Cc: iotivity-dev at lists.iotivity.org
Subject: Re: [dev] Security in IoTivity



On Dec 20, 2016 1:25 AM, "Khaled Elsayed" mailto:khaledieee at gmail.com>> wrote:
Hi,

I am trying to gather some information on the security features in iotivity. I 
know DTLS is used, but is there anything like authorization from devices when 
they are discovered? Is any client capable of discovering whatever device 
running the stack? Is there a document that explain iotivity security with some 
good details?

ha ha ha!

Also, this Internet Draft 
https://tools.ietf.org/html/draft-ietf-core-object-security-01 just came out 
and it proposes using CBOR for application layer security. I know CBOR is used 
in the iotivity stack, so is this ID along the same line of thought in iotivity 
or is the model different?

well, I'm not sure what "same line of thought" means, but my understanding of 
the OCF protocol (actually, OIC 1.1) is that the answer is unequivocally no. 
Iotivity uses CBOR; it does not use  COSE or OSCOAP.  Iotivity security does 
not guarantee info integrity, that's for the application to deal with. Afaik. 
maybe someone with more knowledge will chime in.

hth.

gregg


Best regards,

Khaled



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20161224/4f68d77e/attachment.html>

[dev] Security in IoTivity

[Wong Hon Chan, Neil D]

Hello,

I was interested to use the provisioning APIs in a separate .cpp application; 
specifically on how to get onboarding and provisioning to work between client 
and server in Windows.

I took a look at the c code in 
/resource/csdk/security/provisioning/sample/provisioning.c, and was able to run 
the sample. However when I tried including the headers used above in a modified 
simpleclient.cpp file I ran into various linkage error.

Also there is a separate provisioningclient.cpp sample application under 
/resource/provisioning/examples/ however this sample app is not built when the 
SConsctruct is called when running ?run build? in windows. Trying to run their 
SConscripts lead to various addition linkage error where the .cpp files did not 
know where some of the C methods were implemented.

Is there a set of libs or dll that need to be included to use the C/CPP APIs 
for provisioning?

Thanks,
Neil.

On Tue, Dec 20, 2016 at 12:55 PM, Khaled Elsayed mailto:khaledieee at gmail.com>> wrote:
Hi,

I am trying to gather some information on the security features in iotivity. I 
know DTLS is used, but is there anything like authorization from devices when 
they are discovered? Is any client capable of discovering whatever device 
running the stack? Is there a document that explain iotivity security with some 
good details?

IoTivity Secured Servers can be discovered by any Secured Clients. There is 
nothing like authorization to check whether it is authenticated device. The 
next step after discovery is OT (Ownership Transfer). This Document 
(https://openconnectivity.org/wp-content/uploads/2016/01/Habib-Virji.pdf) can 
provide you details about overall architecture and building/running samples.

http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2015_IoTivitySecurity_0.pdf
Provisioning - https://wiki.iotivity.org/provisioning

Also, this Internet Draft 
https://tools.ietf.org/html/draft-ietf-core-object-security-01 just came out 
and it proposes using CBOR for application layer security. I know CBOR is used 
in the iotivity stack, so is this ID along the same line of thought in iotivity 
or is the model different?

CBOR is essentially used in IoTivity to encode the payload it also used in 
store/retrieve the credentials, Device details etc.,. People here can give you 
more precise details in CBOR in IoTivity


Best regards,

Khaled



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev

-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Gregg Reynolds]

On Dec 20, 2016 1:25 AM, "Khaled Elsayed"  wrote:

Hi,

I am trying to gather some information on the security features in
iotivity. I know DTLS is used, but is there anything like authorization
from devices when they are discovered? Is any client capable of discovering
whatever device running the stack?


I'm going from memory so I could be wrong, but I believe the answer is
"no".  /ooc/d is a resource,  and just like any other resource, access to
it must be granted. so you can configure your device to grant discovery
access only to specific clients (using creds and ACLs). Remember that
"discover" is not an OIC/OCF operation; to discover you send a GET, either
multicast or unicast.

gregg

Is there a document that explain iotivity security with some good details?

Also, this Internet Draft https://tools.ietf.org/html/
draft-ietf-core-object-security-01 just came out and it proposes using CBOR
for application layer security. I know CBOR is used in the iotivity stack,
so is this ID along the same line of thought in iotivity or is the model
different?

Best regards,

Khaled



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Gregg Reynolds]

On Dec 20, 2016 1:25 AM, "Khaled Elsayed"  wrote:

Hi,

I am trying to gather some information on the security features in
iotivity. I know DTLS is used, but is there anything like authorization
from devices when they are discovered? Is any client capable of discovering
whatever device running the stack? Is there a document that explain
iotivity security with some good details?


ha ha ha!


Also, this Internet Draft https://tools.ietf.org/html/
draft-ietf-core-object-security-01 just came out and it proposes using CBOR
for application layer security. I know CBOR is used in the iotivity stack,
so is this ID along the same line of thought in iotivity or is the model
different?


well, I'm not sure what "same line of thought" means, but my understanding
of the OCF protocol (actually, OIC 1.1) is that the answer is unequivocally
no. Iotivity uses CBOR; it does not use  COSE or OSCOAP.  Iotivity security
does not guarantee info integrity, that's for the application to deal with.
Afaik. maybe someone with more knowledge will chime in.

hth.

gregg


Best regards,

Khaled



___
iotivity-dev mailing list
iotivity-dev at lists.iotivity.org
https://lists.iotivity.org/mailman/listinfo/iotivity-dev
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Prakash Karthikeyan]

Welcome ! :)

Thanks,
Karthikeyan Prakash,
Software Engineer,



On Tue, Dec 20, 2016 at 1:52 PM, Khaled Elsayed 
wrote:

> Thanks a lot for the informative reply. This is a useful set of documents.
>
>
> On Tue, Dec 20, 2016 at 10:18 AM, Prakash Karthikeyan <
> prakash.karthikeyan at smartron.com> wrote:
>
>> Hi Kaled,
>>
>> Please find replies In-line.
>>
>> Thanks,
>> Karthikeyan Prakash,
>> Software Engineer,
>>
>>
>>
>> On Tue, Dec 20, 2016 at 12:55 PM, Khaled Elsayed 
>> wrote:
>>
>>> Hi,
>>>
>>> I am trying to gather some information on the security features in
>>> iotivity. I know DTLS is used, but is there anything like authorization
>>> from devices when they are discovered? Is any client capable of discovering
>>> whatever device running the stack? Is there a document that explain
>>> iotivity security with some good details?
>>>
>>
>> IoTivity Secured Servers can be discovered by any Secured Clients. There
>> is nothing like authorization to check whether it is authenticated device.
>> The next step after discovery is OT (Ownership Transfer). This Document (
>> https://openconnectivity.org/wp-content/uploads/2016/01/Habib-Virji.pdf)
>> can provide you details about overall architecture and building/running
>> samples.
>>
>> http://events.linuxfoundation.org/sites/events/files/slides/
>> LinuxConEU2015_IoTivitySecurity_0.pdf
>> Provisioning - https://wiki.iotivity.org/provisioning
>>
>>>
>>> Also, this Internet Draft https://tools.ietf.org/html/dr
>>> aft-ietf-core-object-security-01 just came out and it proposes using
>>> CBOR for application layer security. I know CBOR is used in the iotivity
>>> stack, so is this ID along the same line of thought in iotivity or is the
>>> model different?
>>>
>>> CBOR is essentially used in IoTivity to encode the payload it also used
>> in store/retrieve the credentials, Device details etc.,. People here can
>> give you more precise details in CBOR in IoTivity
>>
>>
>>
>>> Best regards,
>>>
>>> Khaled
>>>
>>>
>>>
>>> ___
>>> iotivity-dev mailing list
>>> iotivity-dev at lists.iotivity.org
>>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>>>
>>>
>>
>> ___
>> iotivity-dev mailing list
>> iotivity-dev at lists.iotivity.org
>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>>
>>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Prakash Karthikeyan]

Hi Kaled,

Please find replies In-line.

Thanks,
Karthikeyan Prakash,
Software Engineer,



On Tue, Dec 20, 2016 at 12:55 PM, Khaled Elsayed 
wrote:

> Hi,
>
> I am trying to gather some information on the security features in
> iotivity. I know DTLS is used, but is there anything like authorization
> from devices when they are discovered? Is any client capable of discovering
> whatever device running the stack? Is there a document that explain
> iotivity security with some good details?
>

IoTivity Secured Servers can be discovered by any Secured Clients. There is
nothing like authorization to check whether it is authenticated device. The
next step after discovery is OT (Ownership Transfer). This Document (
https://openconnectivity.org/wp-content/uploads/2016/01/Habib-Virji.pdf)
can provide you details about overall architecture and building/running
samples.

http://events.linuxfoundation.org/sites/events/files/slides/LinuxConEU2015_IoTivitySecurity_0.pdf
Provisioning - https://wiki.iotivity.org/provisioning

>
> Also, this Internet Draft https://tools.ietf.org/html/
> draft-ietf-core-object-security-01 just came out and it proposes using
> CBOR for application layer security. I know CBOR is used in the iotivity
> stack, so is this ID along the same line of thought in iotivity or is the
> model different?
>
> CBOR is essentially used in IoTivity to encode the payload it also used in
store/retrieve the credentials, Device details etc.,. People here can give
you more precise details in CBOR in IoTivity



> Best regards,
>
> Khaled
>
>
>
> ___
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Ashwini Sharma]

Hello,

There is no authorization from device on discovery. Any client can discover
the devices aroun which are discoverable.

For documebts you can refer wiki.iotivity.org

Thanks
Ashwini

On 20 Dec 2016 12:55 p.m., "Khaled Elsayed"  wrote:

> Hi,
>
> I am trying to gather some information on the security features in
> iotivity. I know DTLS is used, but is there anything like authorization
> from devices when they are discovered? Is any client capable of discovering
> whatever device running the stack? Is there a document that explain
> iotivity security with some good details?
>
> Also, this Internet Draft https://tools.ietf.org/html/
> draft-ietf-core-object-security-01 just came out and it proposes using
> CBOR for application layer security. I know CBOR is used in the iotivity
> stack, so is this ID along the same line of thought in iotivity or is the
> model different?
>
> Best regards,
>
> Khaled
>
>
>
> ___
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Khaled Elsayed]

Thanks a lot for the informative reply. This is a useful set of documents.


On Tue, Dec 20, 2016 at 10:18 AM, Prakash Karthikeyan <
prakash.karthikeyan at smartron.com> wrote:

> Hi Kaled,
>
> Please find replies In-line.
>
> Thanks,
> Karthikeyan Prakash,
> Software Engineer,
>
>
>
> On Tue, Dec 20, 2016 at 12:55 PM, Khaled Elsayed 
> wrote:
>
>> Hi,
>>
>> I am trying to gather some information on the security features in
>> iotivity. I know DTLS is used, but is there anything like authorization
>> from devices when they are discovered? Is any client capable of discovering
>> whatever device running the stack? Is there a document that explain
>> iotivity security with some good details?
>>
>
> IoTivity Secured Servers can be discovered by any Secured Clients. There
> is nothing like authorization to check whether it is authenticated device.
> The next step after discovery is OT (Ownership Transfer). This Document (
> https://openconnectivity.org/wp-content/uploads/2016/01/Habib-Virji.pdf)
> can provide you details about overall architecture and building/running
> samples.
>
> http://events.linuxfoundation.org/sites/events/files/slides/
> LinuxConEU2015_IoTivitySecurity_0.pdf
> Provisioning - https://wiki.iotivity.org/provisioning
>
>>
>> Also, this Internet Draft https://tools.ietf.org/html/dr
>> aft-ietf-core-object-security-01 just came out and it proposes using
>> CBOR for application layer security. I know CBOR is used in the iotivity
>> stack, so is this ID along the same line of thought in iotivity or is the
>> model different?
>>
>> CBOR is essentially used in IoTivity to encode the payload it also used
> in store/retrieve the credentials, Device details etc.,. People here can
> give you more precise details in CBOR in IoTivity
>
>
>
>> Best regards,
>>
>> Khaled
>>
>>
>>
>> ___
>> iotivity-dev mailing list
>> iotivity-dev at lists.iotivity.org
>> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>>
>>
>
> ___
> iotivity-dev mailing list
> iotivity-dev at lists.iotivity.org
> https://lists.iotivity.org/mailman/listinfo/iotivity-dev
>
>
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Khaled Elsayed]

Hi,

I am trying to gather some information on the security features in
iotivity. I know DTLS is used, but is there anything like authorization
from devices when they are discovered? Is any client capable of discovering
whatever device running the stack? Is there a document that explain
iotivity security with some good details?

Also, this Internet Draft
https://tools.ietf.org/html/draft-ietf-core-object-security-01 just came
out and it proposes using CBOR for application layer security. I know CBOR
is used in the iotivity stack, so is this ID along the same line of thought
in iotivity or is the model different?

Best regards,

Khaled
-- next part --
An HTML attachment was scrubbed...
URL: 

[dev] Security in IoTivity

[Agrawal, Sachin]

>-Original Message-
>From: Leo Dorrendorf [mailto:Leo.Dorrendorf at sansasecurity.com]
>Sent: Tuesday, January 13, 2015 12:00 PM
>To: Agrawal, Sachin; iotivity-dev at lists.iotivity.org
>Subject: RE: Security in IoTivity
>
>Hi Sachin,
>
>Thank you for the detailed response - that really helps.
>Are there any design documents regarding provisioning/bootstrapping? Could
>you point me to contributors? If we're getting involved in OIC and IoTivity, 
>I
>expect that's where we can help the most.
>
>Thank you,
>Leo.

Hi Leo,

Unfortunately, we have not been able to document security related info on the 
Iotivity Wiki. We plan to do that soon and will send you a link.
If you want to participate in OIC standards discussion, you can become an OIC 
member and join the Security Working Group: http://openinterconnect.org/join/

Thanks
Sachin


-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7768 bytes
Desc: not available
URL: 

[dev] Security in IoTivity

[Agrawal, Sachin]

Hi Leo,

Welcome to Iotivity!!

Here is a brief summary of security within Iotivity:

-Devices existing in Iotivity system can exhibit data confidentiality by 
protecting the communication channel using DTLS-PSK cipher 
(TLS_PSK_WITH_AES_128_CCM_8).
-Authorization within Iotivity is managed using Access Control Lists which 
itself are modeled as resources. Each resource hosts a ACL which can be 
remotely queried/updated using REST API?s. Among other things, these ACL?s can 
provide role based and time based access control.
-Different groups are working on adding ?provisioning/bootstrapping? features 
which will allow a new device to be configured with credentials necessary to 
participate in a local Iotivity ecosystem. Since capabilities (power, memory 
and processor speed) of various IoT devices will vary, we are working on a set 
of schemes which range from ?unauthenticated provisioning? to ?signed DH 
provisioning?.

Thanks
Sachin

From: iotivity-dev-bounces at lists.iotivity.org 
[mailto:iotivity-dev-boun...@lists.iotivity.org] On Behalf Of Leo Dorrendorf
Sent: Tuesday, January 13, 2015 4:28 AM
To: iotivity-dev at lists.iotivity.org
Subject: [dev] Security in IoTivity

Hi everyone,

I've just joined this list and checked out the IoTivity code. Looking through 
it I see that it uses DTLS with X509 certificates for security.
However, I could use a higher-level explanation of security in IoTivity: what 
is the procedure for a device to join a network? Does IoTivity feature 
authorization between services, and so on?
I would be grateful for links to any documentation or a contact to talk to 
about this.

Thank you,

Leo Dorrendorf | Director of Technology Strategy
Office: +972-73-255-8728 | Mobile: +972-52-681-8594 | Fax: +972-73-255-8728
Email: leo.dorrendorf at sansasecurity.com | www.sansasecurity.com

-- next part --
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7768 bytes
Desc: not available
URL: 
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150113/7892c84e/attachment.p7s>