Re: [m2m-iwg] M3DA presentation - Security

[Cuero Bugot <cbugot@xxxxxxxxxxxxxxxxxx>]

Not sure, but it looks like there is a misunderstanding.

There is no User authentication here. We are discussing authentication of a device using a M2M dedicated protocol (M3DA).

The user authentication would be on another segment of the chain: on the server side, where it is totally standard to use HTTP/SSL, OAuth and other complete/complex solutions.

 

Device+Sensors <----M3DA-----> Server <-------HTTPS--------> User

 

De : m2m-iwg-bounces@xxxxxxxxxxx [mailto:m2m-iwg-bounces@xxxxxxxxxxx] De la part de Matteo Collina
Envoyé : mardi 12 mars 2013 19:46
À : m2m Industry Working Group
Objet : Re: [m2m-iwg] M3DA presentation - Security

 

 

Hi Rick,

You made a very good point, but I still have some questions.

2013/3/12 Rick Bullotta <rick.bullotta@xxxxxxxxxxxxx>

I’m quite familiar with OAuth – we use it quite often to authenticate against backend apps and data sources, but I don’t think it is the appropriate on-device authentication mechanism or even the right technique for device -> cloud.  It is better suited towards authentication on a “sensor cloud” or other intermediate server that exposes the device data/capabilities. 

Could you please expand this point?

Why these use cases are different?

Perhaps there are some scenarios where OAuth could be used in an on-site gateway to provide access to other users/apps, but in general, OAuth is a fairly poor choice for securing M2M applications due to the lack of granular ACLs.  It tends to be used for “all or nothing” access control.  

I totally agree with you. However a user/password model does not support ACL out of the box.

M2M applications require a far more granular security model, including read/write access at an individual sensor/actuator level.  That would quickly become totally unmanageable using OAuth.

I am speaking about protecting end users, not the sensors/actuators.

As a User, I want only "my" thermostat to access to my cloud profiles, and vice versa.

Storing an OAuth-like token directly inside the device will certainly help security and privacy.

 

I understand that you are suggesting to use two different protocols for authorizing user to access sensors/actuators.

In your architecture, OAuth might be used for authorizing users to access the "cloud", and then another protocol/authentication scheme for the communication between sensors/actuators and the cloud.

Why OAuth is not capable of both?

I think it is important to avoid falling into the trap of universally leveraging technologies that were designed for social apps (which are very “non mission critical”) for applications in the M2M space.

I am speaking about non-mission-critical solutions. I certainly do not want OAuth inside a nuclear reactor or a factory plant.

Still, the explosion of "consumer" technologies such as OAuth might radically change this field.

 

Thanks,

 

Matteo